Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
who's reconfigged my LAN? [NOT solved]
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe

PostPosted: Tue Oct 29, 2013 3:53 pm    Post subject: Reply with quote

Resume so far:

Jaglover; I believe this is the fallback address you get if your network connection cannot be established.

I'd already mentioned APAPI, the question is why is this interface not using the fixed IP provided.

NeddySeagoon: I guess your net file is in a mess ?

Good guess but , no.


NeddySeagoon:Look in emerge.log to see what got updated in the last 3 or 4 days

Not neither.

aim nano : Perhaps their is an issue, then, with your DHCP server/modem/router... broken DHCP server

DHCP seems to work, what you are suggesting is broken client. Where is evidence of this being a known issue?


Hu: Although this is not the root of your problem, setting your address as a /8 when you are clearly using the standard reserved address range is wrong. You probably want a /24.

right , so that's another thing that is NOT the cause of this problem.


Tom Wij: If you don't have that udev rule and use the name it normally gives, can you still replicate the problem?

Yes, so it's not that either.

---------o : Regardless of whether you've added static ip some mechanism in modern routers trigger dhcp.

Sounds rather nonsensical since it is the dhcp CLIENT that runs on gentoo. It is the client that "triggers" dhcp , not the server.



After that, five posts by me with no reply from anyone.

Guess we're out of ideas of a possible explanation then. :(
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Tue Oct 29, 2013 8:34 pm    Post subject: Reply with quote

Gentree,

dhcp is the default for any interface not listed in the net file.
your interface starts out with a ethX assigned by the kernel
It may get a udev permanent name before your own rule renames it again

Maybe dhcpcd runs when the interface has one of its transient names and it is therefore not listed in the net file.
dmesg may help.
_________________
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
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe

PostPosted: Tue Oct 29, 2013 8:56 pm    Post subject: Reply with quote

Thanks Neddy.

As previously posted output shows, the udev renaming happens during boot phase. dhcpd seems to be the first thing to happeni in runlevel 3 by which time I have the renamed interfaces. As the experiment of removing renaming showed this is not a factor and some critical time oddity is not the cause.


If I add net.eth_real to default , it gets configured from conf.d/net but dhcpd no longer fires and I don't get WLAN.

I have added both net.eth_real and net.eth_real (the outward pointing NIC) to default and get network configured in an equivalent state to before but cannot guarantee this is the same way I had it before.

One think is sure, I did not use rc-update to remove them nor explicitly touch network config in any way to provoke this change.

Exactly what broke the LAN config remains a mystery.
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Tue Oct 29, 2013 9:13 pm    Post subject: Reply with quote

Gentree,

How does dhcpcd get run?

Is it in your default runlevel or called by the network startup script?
_________________
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
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe

PostPosted: Tue Oct 29, 2013 10:23 pm    Post subject: Reply with quote

No, dhcpcd is not explicitly in any runlevel.
hotplug is in runlevel 3 but I don't see anything in logs explicitly stating it as starting

current log (with both net.eth scripts explicitly in default) looks that same as before:
Code:
Oct 29 22:27:19 localhost init: Entering runlevel: 3
Oct 29 22:27:20 localhost dhcpcd[1892]: version 5.5.6 starting
Oct 29 22:27:20 localhost dhcpcd[1892]: all: not configured to accept IPv6 RAs
Oct 29 22:27:20 localhost dhcpcd[1892]: eth_mobo: rebinding lease of 192.168.0.10



conf.d/net specifies it to use dhcp but as noted above it was still doing this even when that file was not present.

conf.d/net seems to get called when a net.eth* is explicitly started. If none are in rc-update -s it is not read.

Quote:
dhcp is the default for any interface not listed in the net file.


Default for what? What needs a default ? Knowing what process is triggering all this may help in understanding how it is configured and why it is or is not running.

I get the impression you know and you are just pointing me to asking the right question.

If you have an idea what is running what it may speed things to up a bit to say so. I'm going to have quit for tonight very shortly.

thanks.
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Tue Oct 29, 2013 10:51 pm    Post subject: Reply with quote

It really sounds like /etc/conf.d/net isn't read at all somehow.

$ md5sum /etc/init.d/net.lo
be4d4227cd5c7647493edae9131f1798 /etc/init.d/net.lo

1. Please verify that you get the same result as above; if not, remove it and merge net-misc/netifrc again.

2. Remove any other /etc/init.d/net.* entries.

3. Symlink the entries again.

4. Use `rc-update add net.* default` for each entry you want to start by default.

5. Ensure /etc/conf.d/net has what you want it to do.

6. Reboot.

I think this should ensure /etc/conf.d/net is read; if not, you are suggested to file a bug at https://bugs.gentoo.org such that the maintainers can look further into what happened and how to fix it.
Back to top
View user's profile Send private message
Aiken
Apprentice
Apprentice


Joined: 22 Jan 2003
Posts: 239
Location: Toowoomba/Australia

PostPosted: Tue Oct 29, 2013 11:08 pm    Post subject: Reply with quote

TomWij wrote:

$ md5sum /etc/init.d/net.lo
be4d4227cd5c7647493edae9131f1798 /etc/init.d/net.lo

1. Please verify that you get the same result as above; if not, remove it and merge net-misc/netifrc again.


That looks like you are running unstable. My system is running stable and the md5 of my /etc/init.d/net.lo is 564bc20feda1883b3f7001cdbb3cfa04 and it comes from openrc.
_________________
Beware the grue.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Wed Oct 30, 2013 12:26 am    Post subject: Reply with quote

Err, sorry, I thought that change happened to stable yet, I was wrong and haven't checked that; though given that the hash is different, maybe it is interesting to try the unstable version?

Regardless, thank you for posting the stable hash such that he can check against that instead.
Back to top
View user's profile Send private message
ChrisJumper
Advocate
Advocate


Joined: 12 Mar 2005
Posts: 2389
Location: Germany

PostPosted: Wed Oct 30, 2013 1:34 am    Post subject: Reply with quote

Hi Gentree!

If you have still your /etc/conf.d/net like that:

Code:
config_eth_real="192.168.212.3/8"

dhcpcd_wlan0=" -C resolv.conf"
dhcpcd_wlan1=" -C resolv.conf"

config_eth_mobo="dhcp"
dhcpcd_eth_mobo=" -C resolv.conf"


Your issue should be that your udev-Rule named your device eth0 and your rules aim at a device named eth_real.

Try 192.168.212.3 with a slash 24 netmask:
Code:
config_eth0="192.168.212.3 netmask 255.255.255.0 brd 192.168.2.255"


Or if you really use a slash 8 netmask:
Code:
config_eth0="192.168.212.3 netmask 255.0.0.0 brd 192.168.2.255"




Gentree wrote:


Well, I seems to be discussing this with myself by this stage but just in case:


I inserted a garbage line into /etc/conf.d/net and it produced no error.

Code:
init 3


messages:
Code:
Oct 29 11:19:36 localhost init: Entering runlevel: 3
Oct 29 11:19:37 localhost dhcpcd[1774]: version 5.5.6 starting
Oct 29 11:19:37 localhost dhcpcd[1774]: all: not configured to accept IPv6 RAs
Oct 29 11:19:37 localhost kernel: [   14.064341] eth_real: link up, 100Mbps, full-duplex, lpa 0x41E1
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: checking for 169.254.102.87
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: rebinding lease of 192.168.0.10
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: carrier lost
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: carrier acquired
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: checking for 169.254.102.87
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: carrier lost
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: carrier acquired
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: rebinding lease of 192.168.0.10
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: acknowledged 192.168.0.10 from 192.168.0.254
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: checking for 192.168.0.10
Oct 29 11:19:42 localhost dhcpcd[1774]: eth_real: using IPv4LL address 169.254.102.87
Oct 29 11:19:42 localhost dhcpcd[1774]: forked to background, child pid 1824
Oct 29 11:19:42 localhost dhcpcd[1824]: eth_mobo: leased 192.168.0.10 for 864000 seconds



Wow with your init 3, your system switching to Init Lvl 3 :)

I think your issue is that the Network-Device names have changed. Your udev-Rule:

Code:
# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:08:a1:73:74:e9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

Will declare your Network-Device as eth0.

What Names use ifconfig you have after your System boot?

And are you sure that your cleaning lady or cleaner did not unplug your Lan cable and put the plug back in the wrong Networkcard? But i suppose that you got the update of udev which rename your device-names if you have no rule as described before.
Back to top
View user's profile Send private message
Chiitoo
Administrator
Administrator


Joined: 28 Feb 2010
Posts: 2550
Location: Here and Away Again

PostPosted: Wed Oct 30, 2013 2:08 am    Post subject: ><)))°€ Reply with quote

Heya. ö/

Just a bit of a side-question from the sidelines!

TomWij wrote:
I think this should ensure /etc/conf.d/net is read; if not, you are suggested to file a bug at https://bugs.gentoo.org such that the maintainers can look further into what happened and how to fix it.

Would that really be prudent, considering for one, they are using dhcpcd-5.5.6 (which, I think, was removed from Portage nearly 10 months ago)?

Just wondering. ^^;


As for the issue, I doubt I could come up with any better ideas. It does certainly seem like a very interesting one, especially since there has been “no emerge activity since June”. If no configuration files have been modified either, first thing that comes to my mind are external changes (router box, cables, and so on and so forth).

I wouldn't probably get /too/ paranoid just yet. Just.


Best of luck on your journey towards closure on this!
_________________
Kindest of regardses.
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Wed Oct 30, 2013 2:30 am    Post subject: Reply with quote

Well spotted, interesting, can you (Gentree) check why the dhcpcd is like that? The latest stable seems to be different; so, maybe upgrading the system might yield a difference...
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe

PostPosted: Wed Oct 30, 2013 6:09 am    Post subject: Reply with quote

TomWij, this system is badly out of date. Part of my aim in looking at this is to decide whether it is worth updating (which will be problematic) or install a fresh system (which will be a PITA to get all the tweaks and configs just the way I want it like the current system). Either way I have a significant time investment that I'm not looking forward to.

Before considering introducing even more problems by changing package versions I need to know this box is in a stable state and essentials like networking are in a know running state. Until last week that had bee the case for a very long time.

something happened that broke networking and I still have little idea what caused that change. That, I do not like.
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Wed Oct 30, 2013 9:00 pm    Post subject: Reply with quote

Gentree

Code:
# PCI device 0x10ec:0x8139 (8139too)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:08:a1:73:74:e9", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"


What version of udev do you have?
udev-17? approx was the last version that supported renaming to kernel names

Hot plugging starts all detected interfaces. They need not be listed in the default runlevel.
See the comments in /etc/rc.conf

Try listing your transient interface names in the
Code:
rc_hotplug="!net...."
entry
_________________
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
eyoung100
Veteran
Veteran


Joined: 23 Jan 2004
Posts: 1428

PostPosted: Wed Oct 30, 2013 9:27 pm    Post subject: Reply with quote

See last post: Wireless adapter always going to 169.254.xxx.xxx?

I believe you are experiencing a hardware failure in your Ethernet Adapter, eth_real
_________________
The Birth and Growth of Science is the Death and Atrophy of Art -- Unknown
Registerd Linux User #363735
Adopt a Post | Strip Comments| Emerge Wrapper
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


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

PostPosted: Wed Oct 30, 2013 9:42 pm    Post subject: Reply with quote

eyoung100,

... but dhcpcd shold never be run for the interface.
It should get the statically assigned IP, or no IP at all
_________________
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
eyoung100
Veteran
Veteran


Joined: 23 Jan 2004
Posts: 1428

PostPosted: Wed Oct 30, 2013 9:58 pm    Post subject: Reply with quote

What's the default behavior of the *.net scripts, if manually assigning an IP Address Fails :?: Following Logic:

Manual Assignment Fails for eth_real :arrow: Other Scripts Require net to be up :arrow: Fallback to DHCP Assignment for eth_mobo :arrow: Manual Assignment tried again for eth_real, and Fails due to Hardware Failure. Evidence is in log:

Code:
Oct 29 11:19:36 localhost init: Entering runlevel: 3
Oct 29 11:19:37 localhost dhcpcd[1774]: version 5.5.6 starting
Oct 29 11:19:37 localhost dhcpcd[1774]: all: not configured to accept IPv6 RAs
Oct 29 11:19:37 localhost kernel: [   14.064341] eth_real: link up, 100Mbps, full-duplex, lpa 0x41E1
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: checking for 169.254.102.87 <-- Previous Address Failure Released
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: rebinding lease of 192.168.0.10
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: carrier lost <--Address Assignment Fails
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: carrier acquired <--Address Assignment Retries and fails again
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real: checking for 169.254.102.87 <--Static Attempt Fails
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: carrier lost
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: carrier acquired
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: rebinding lease of 192.168.0.10
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: acknowledged 192.168.0.10 from 192.168.0.254
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo: checking for 192.168.0.10
Oct 29 11:19:42 localhost dhcpcd[1774]: eth_real: using IPv4LL address 169.254.102.87
Oct 29 11:19:42 localhost dhcpcd[1774]: forked to background, child pid 1824 <--Failing Card forked to background, because comms failed at DHCP Server Whiile Repeating Above Arrowed Steps
Oct 29 11:19:42 localhost dhcpcd[1824]: eth_mobo: leased 192.168.0.10 for 864000 seconds


the DHCP Server is irrelevant here, but the Carrier Signal still needs to communicate with the router to tell the router, "Hey, I'm taking this address<static address> don't give it to anyone else," and that communication is failing when the process is forked. The process is forked because the self-assigned IP address cannot be released.

Hunch: Does this failure also occur on Windows, if machine has Windows :?:
_________________
The Birth and Growth of Science is the Death and Atrophy of Art -- Unknown
Registerd Linux User #363735
Adopt a Post | Strip Comments| Emerge Wrapper
Back to top
View user's profile Send private message
TomWij
Retired Dev
Retired Dev


Joined: 04 Jul 2012
Posts: 1553

PostPosted: Wed Oct 30, 2013 10:31 pm    Post subject: Reply with quote

dhcpcd shouldn't be working on that interface if it were configured as static; so, those lines shouldn't appear in the log at all. Dunno about a hardware failure, it appears that dmesg doesn't report it; so, it would be a silent hardware failure if it is. I stay by the thought that /etc/conf.d/net isn't getting read for one or another reason.

Given that the system has became outdated, this might be some bug with something that has since already been resolved; the interesting thing though, is that this just so suddenly happened which makes me think back about the timing bug mentioned near the start of the thread. Another option is that dhcpcd is somehow ran independent from the net scripts; but well, I suppose that would be known if that were the case.

I'd say a try to update or a reinstall is adviced to ensure a recent system; because well, at this point one would have to use more low level debugging techniques (changing the openrc shell scripts, firing up tcpdump or wireshark and look what goes wrong with the protocol, etc...) which might take longer than to just upgrade or reinstall the entire system instead.


Last edited by TomWij on Wed Oct 30, 2013 10:37 pm; edited 3 times in total
Back to top
View user's profile Send private message
eyoung100
Veteran
Veteran


Joined: 23 Jan 2004
Posts: 1428

PostPosted: Wed Oct 30, 2013 10:35 pm    Post subject: Reply with quote

Humor me, and replace the card. If it doesn't fix it, everyone here is welcome to say I Told You So!
_________________
The Birth and Growth of Science is the Death and Atrophy of Art -- Unknown
Registerd Linux User #363735
Adopt a Post | Strip Comments| Emerge Wrapper
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe

PostPosted: Thu Oct 31, 2013 11:10 am    Post subject: Reply with quote

Quote:
I stay by the thought that /etc/conf.d/net isn't getting read for one or another reason.

That is the case unless I add net.eth_mobo and net.eth_real to default.

It seems that without that, hotplug is running dhcpcd automatically and /etc/conf.d/net is not read at all. I confirmed that above by adding a deliberate syntax error and finally removing it altogether.


@ Neddy
dmesg | grep udev
[ 6.514642] udev: starting version 151
[ 7.002365] udev: renamed network interface eth0 to eth_real
[ 7.255754] udev: renamed network interface eth0 to eth_mobo

udev 151, last one to recognise /dev/hd* device names.

Removing that limitation was what started the kernel changes. All drives are now on /dev/sd* but I have not changed udev or any other packages because I want to know what broke networking in the few days I was making ata/sata change over.
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86
Back to top
View user's profile Send private message
_______0
Guru
Guru


Joined: 15 Oct 2012
Posts: 521

PostPosted: Thu Oct 31, 2013 2:44 pm    Post subject: Reply with quote

Could this be related to the newnet USE flag in udev or openrc? I remember that was a headache.
What about some other program starting dhcp? Are you running a full blown DE by any chance?
Back to top
View user's profile Send private message
UberLord
Retired Dev
Retired Dev


Joined: 18 Sep 2003
Posts: 6835
Location: Blighty

PostPosted: Thu Oct 31, 2013 3:26 pm    Post subject: Reply with quote

Code:
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_real
Oct 29 11:19:37 localhost dhcpcd[1774]: eth_mobo


So the same instance of dhcpcd (as they have the same PID is working on two interfaces).
This means that dhcpcd is being started by /etc/init.d/dhcpcd (check for runlevels for it's presence).
As such it will ignore any conf.d/net rules you have inplace.

This is generally a good thing btw and how dhcpcd is designed to work since dhcpcd-5 especially on a multi homed system such as a laptop with wired and wireless potentially on the same subnet.

Also, you need dhcpcd-6.1.x to work well with udev device renaming OR have dhcpcd depend on udev-settle or similar if in the same runlevel or using something like systemd.
_________________
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
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe

PostPosted: Fri Nov 01, 2013 10:13 pm    Post subject: Reply with quote

thanks for the details, your uberness.

Code:
This means that dhcpcd is being started by /etc/init.d/dhcpcd (check for runlevels for it's presence).
As such it will ignore any conf.d/net rules you have inplace.


That would explain net rules being ignored, thanks. However, dhpdcd is not in any run level.

I'm still unclear of the precise trigger for dhcpcd being the first thing to post output on runlevel 3 starting.

There were two clear changes in behaviour when this started. Firstly eth_real was getting dhcp APIPA fallback IP instead of the hard coded net rules static.

Secondly, during startup when router was not powered up I would have to wait for dhcp time-outs on eth_mobo, this was no longer after the change (or perhaps it was not visible once X11 came up, whereas I normally noticed it since I see boot messages scrolling).



These observations lead me to conclude that eth_real and eth_mobo were is default RL as they are again now and net setup seems to behave as before the problem.

All I was working on last w/e was changing ata/sata in kernel. I don't see any way this could have affected network settings.

I have a vague recollection of reviewing rc content many months ago. Is there any mechanism which could have cached the static IP on eth_real since then if I had removed it from the runlevel configuration at that time and that could have been cleared by the kernel rebuild last week?
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86
Back to top
View user's profile Send private message
UberLord
Retired Dev
Retired Dev


Joined: 18 Sep 2003
Posts: 6835
Location: Blighty

PostPosted: Sun Nov 03, 2013 3:31 pm    Post subject: Reply with quote

Gentree wrote:
That would explain net rules being ignored, thanks. However, dhpdcd is not in any run level.


Then maybe something is depending on it OR something is starting it with either 0 or >1 interface names.
I've not used Gentoo in ages, but iirc the rc-status command should show all services running in the runlevel.
If dhcpcd is running AND dhcpcd is listed then the former is true.
If dhcpcd is running AND dhcpcd is not listed then the latter is true. This is more tricky to find, but would either be the Gentoo net scripts or something like NetworkManager.

Quote:

Secondly, during startup when router was not powered up I would have to wait for dhcp time-outs on eth_mobo, this was no longer after the change (or perhaps it was not visible once X11 came up, whereas I normally noticed it since I see boot messages scrolling).


Could be that one of your dhcpcd config settings is turning off carrier detection OR the carrier detection on eth_mobo is faulty.
If the router isn't powered then the carrier should be down, assuming a direct connection. If via a hub/switch then ofc carrier would be up and you're SOL.

Quote:

I have a vague recollection of reviewing rc content many months ago. Is there any mechanism which could have cached the static IP on eth_real since then if I had removed it from the runlevel configuration at that time and that could have been cleared by the kernel rebuild last week?


Very doubtful.
dhcpcd and dhclient do cache the last assigned address and try to re-use it, but this shouldn't affect any static config you may have.
_________________
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
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5350
Location: France, Old Europe

PostPosted: Mon Nov 04, 2013 9:48 am    Post subject: Reply with quote

Thanks again,

in default run level to most likely things to cause dhpcd to start are netmount and udev-postmount.

Since, without the devices being explicitly started via net.eth* there will be nothing up, that is not worrying that something is triggering it.

My underlying mystery in all this is that something changed last week and I did not do it.

Clearly eth_mobo ( the DHCP configure net did use to be run in the boot run level since it used to hold up the boot process if the router was off.

The static device did used to get configured until the change last week. This would seem to imply that eth_real was being started explicitly before that time.

Since it seems high-fliers like Neddy and Uberlord can't see how my kernel change could have done this and considerable discussion has not shown anything that could account for the static rules being read without having eth_real started explicitly somewhere, I'm left with a problem to explain what changed my network config.


That is a worry.
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.
Gentoo because I'm a masochist
AthlonXP-M on A7N8X. Portage ~x86
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 Nov 04, 2013 10:52 am    Post subject: Reply with quote

To be fair, I'm just talking about dhcpcd here.
I've not used Gentoo directly for years.

But still, the most likely candidates for the change with be udev, openrc, netcfg scripts (i believe they have been slit from openrc now).
I really don't think that the kernel is at fault, nor is dhcpcd directly as it's just doing what it's told to.
_________________
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
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
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