emanuel wrote:

On Friday, January 27, 2017 10:06:13 PM PST David C. Rankin wrote:

...

All,

I use this same laptop with both Leap and Arch, wpa/wireless. With Arch/netctl the IP is established in 13 seconds. With Leap/wicked it consistently takes 39 seconds.

Is there some way to speed up the network connection? i would look at what is going on via systemctl, run> systemctl status *dhcp* see if there is anything interesting.

There is no such service on a client - dhcp is done by wicked or NetworkManager. "systemctl status wicked" doesn't say much. -- Per Jessen, Zürich (1.6°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

David C. Rankin wrote:

...

All,

I use this same laptop with both Leap and Arch, wpa/wireless. With Arch/netctl the IP is established in 13 seconds. With Leap/wicked it consistently takes 39 seconds.

There was/is some bugreport on slow network start-up (30 sek delay?), but I'm pretty certain it was fixed. I have not noticed any such long delays on my Leap422 laptop.

Checking my leap422 desktop, it does take 20 seconds for eth0 to get started. (from systemd-analyze blame). Looking the logs, from the time the driver reports "Link is up at 1000 Mpbs" until wicked reports "eth0 up" takes 16 seconds. For instance: https://bugzilla.opensuse.org/show_bug.cgi?id=1013918 -- Per Jessen, Zürich (-1.5°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

sdm wrote:

On 01/28/2017 01:30 AM, Per Jessen wrote:

...

Checking my leap422 desktop, it does take 20 seconds for eth0 to get started. (from systemd-analyze blame). Looking the logs, from the time the driver reports "Link is up at 1000 Mpbs" until wicked reports "eth0 up" takes 16 seconds.

For instance: https://bugzilla.opensuse.org/show_bug.cgi?id=1013918

Doesn't Windows 7 or 10 get a DHCP address in a matter of seconds?

Dunno, I don't use either one.

I have always noticed the wicked service hangs up for 20-30 on boot when requesting a DHCP address. IMO this should happen in 2-3 seconds, not half a minute.

The actual dhcp exchange that less than a second: Jan 28 10:06:15 dresden dhcpd: DHCPREQUEST for 192.168.3.34 from 00:18:fe:6a:73:0b via eth0 Jan 28 10:06:15 dresden dhcpd: DHCPACK on 192.168.3.34 to 00:18:fe:6a:73:0b via eth0 but that isn't the full story. -- Per Jessen, Zürich (-0.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Richmond wrote:

According to journalctl wickedd took 19 seconds. But I am wondering if it is trying to start up ipv6 and failing. It took 10 seconds to get an IPV4 address.

I think I got it down to 9 seconds by disabling IPV6 and DHCPV6. Although it still says: "Started wicked DHCPv6 supplicant service." -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

We have IPv6 too, but there was some report about that delay somehow being tied to IPv6, I just can't find it.

Was it the one with /etc/gai.conf in it where ipv4 was given higher precedence? Have the following in /etc/gai.conf near end: # > 2.7. To change private IPv4 address scope # > # > As detailed in Remi's draft [I-D.denis-v6ops-nat-addrsel], when a # > host is in NATed site, and has a private IPv4 address and # > transitional addresses like 6to4 and Teredo, the host chooses # > transitional IPv6 address to access most of the dual-stack servers. # > # > This is because private IPv4 address is defined to be site-local # > scope, and as in RFC 3484, the scope matching rules (Rule 2) set # > lower priority for private IPv4 address. # > # > By changing the address scope of private IPv4 address to global, this # > problem can be solved. # scopev4 ::ffff:10.0.0.0/104 14 scopev4 ::ffff:172.16.0.0/108 14 scopev4 ::ffff:192.168.0.0/112 14 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/28/2017 03:30 AM, Per Jessen wrote:

Per Jessen wrote:

...

David C. Rankin wrote:

...

All,

I use this same laptop with both Leap and Arch, wpa/wireless. With Arch/netctl the IP is established in 13 seconds. With Leap/wicked it consistently takes 39 seconds.

There was/is some bugreport on slow network start-up (30 sek delay?), but I'm pretty certain it was fixed. I have not noticed any such long delays on my Leap422 laptop.

Checking my leap422 desktop, it does take 20 seconds for eth0 to get started. (from systemd-analyze blame). Looking the logs, from the time the driver reports "Link is up at 1000 Mpbs" until wicked reports "eth0 up" takes 16 seconds.

For instance: https://bugzilla.opensuse.org/show_bug.cgi?id=1013918

That's more what I'm seeing. There is just an additional 20 sec. delay (approx.) in the whole IP configuration routine. (it is also dangerous as HELL to have 'nolimit' (or no timeout) set on the connection. Attempting to boot the laptop at another location where there is no wpa config would just hang forever... -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

David C. Rankin wrote:

Just for the record, I have IPv4 infrastructure, but do not disable IPv6 in SuSE (or Arch for that matter). If there is an issue in openSuSE where the IPv6 negotiation where none is present, that would point to a problem with how wicked handles that circumstance. As netctl on Arch handles that circumstance without an issue.

---- Well Per doesn't think this is what's going on, but this seems to describe your problem: (from /etc/gai.conf) # # This default differs from the tables given in RFC 3484 by handling # (now obsolete) site-local IPv6 addresses and Unique Local Addresses. # The reason for this difference is that these addresses are never # NATed while IPv4 site-local addresses most probably are. Given # the precedence of IPv6 over IPv4 (see below) on machines having only # site-local IPv4 and IPv6 addresses a lookup for a global address would # see the IPv6 be preferred. The result is a long delay because the # site-local IPv6 addresses cannot be used while the IPv4 address is. ... # The problem scenario is the following: # # An end user is located in a network numbered with private (RFC 1918) IPv4 # addresses and transitional 6to4 (RFC 3056) IPv6 addresses. The network is # connected to the internet by a CPE/SOHO device implementing NAT for IPv4 and # anycasted 6to4 (RFC 3068) for IPv6. # # When the user attempts to connect to a server whose hostname has both IPv4 # and IPv6 addresses published in DNS, an IPv6 connection using the # transitional 6to4 service will be preferred. This happens because the scope # comparsion fails for IPv4, the RFC 1918 addresses are assumed to have # site-local scope, which is smaller than the global scope of the server's IPv4 # address. For IPv6, both the server's and the client's (6to4) address have # global scope. # # Unfortunately, the operational reality is that a transitional technique such # as 6to4 is much less reliable than IPv4. The relay routers might be located # far away from the optimal IPv4 path, and thus cause a significant latency # increase, or they might not even work optimally (they're usually operated by # voulenteering third parties on a best-effort basis), and finally some ISPs # simply filter away all proto-41 traffic. Transitional techniques are useful # to give end users with IPv4-only service a real shot at accessing IPv6-only # content, but it should never be preferred over IPv4 service when accessing # dual-stacked content. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

David C. Rankin wrote:

Jan 26 12:00:48 wizard wickedd-dhcp4[1214]: wlan0: Committed DHCPv4 lease with address 192.168.6.104 (lease time 28800 sec, renew in 14400 sec, rebind in 25200 sec) Jan 26 12:00:48 wizard wickedd[1220]: wlan0: Notified neighbours about IP address 192.168.6.104 Jan 26 12:01:13 wizard wicked[1228]: lo up Jan 26 12:01:13 wizard wicked[1228]: eth0 setup-in-progress Jan 26 12:01:13 wizard wicked[1228]: wlan0 up

That is weird. I can't see why it might do that -- like it is waiting for 25 seconds to see if other hosts might claim a collision, but why so long? ... Ahhh... Found in sample file /usr/share/doc/packages/wicked/samples/wicked/eth0-dhcp.xml ... <link-detection> <require-link /> <timeout>10</timeout> </link-detection> and ipv4:dhcp <enabled>true</enabled> <acquire-timeout>15</acquire-timeout> ---- 10+15 = 25? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/29/2017 03:25 PM, David C. Rankin wrote:

10+15 = 25 is too "dead on" to be a coincidence. This has to figure into to the delay.

Why is it waiting the full time out period when you DO have a connection? -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

David C. Rankin wrote:

Now we are cooking... So how do I find out is this is triggered by the "on-cable-connect" setting for eth0?

10+15 = 25 is too "dead on" to be a coincidence. This has to figure into to the delay.

looks like wicked has some files /etc/wicked/ifconfig/xxxx. There are also server files that look like: /etc/dbus-1/system.d/org.opensuse.Network.AUTO4.conf /etc/dbus-1/system.d/org.opensuse.Network.DHCP4.conf /etc/dbus-1/system.d/org.opensuse.Network.DHCP6.conf /etc/dbus-1/system.d/org.opensuse.Network.Nanny.conf /etc/dbus-1/system.d/org.opensuse.Network.conf Then ... maybe /etc/sysconfig/network/config scripts/settings for boot + manual and in /etc/sysconfig/wicked might be some debug options to turn on but "onplug" events would be handed by udevd(sysd version)... So maybe some udevd script/config file... used to be in /etc/udev/rules.d/xx-network.rules? telling it to start a script under /etc/sysconfig/network/scripts/ifup-sysctl... which might read the configs under /etc/sysconfig/network/if-<intfname>? (just pokin through the wicked rpm on my 13.2 setup...had to install it to see what was in it...)... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/29/2017 07:38 PM, L A Walsh wrote:

It is hinting at What John Andersen asked about -- just how good is your connection on this wifi? Maybe interference is slowing things down as mentioned in the article? Maybe 1 set of software is using one connect method and the other uses a different one?

I don't have any wireless connects -- too much interference (I couldn't get a clean signal across my living room (~10-15 feet max) for a wireless speaker. Ended up running wires around the edge of the room for audio & power (wanted power to sub-woofer to be controlled by the home-A/V unit). Also had security and speed concerns: my lan speeds, here, run over 1-10Gb links. Was willing to take a hit in convenience for better lan-speed. :-)

Wireless is flawless. AP is about 20 ft. + 1 wall from the laptop. Doing the wireless config manually, each step is instantaneous. It's looking like 10+15+dbus+something screwy with "on cable connect" is the culprit. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/31/2017 06:05 PM, L A Walsh wrote:

Hope you find it -- am sorta at the end of my ideas since I don't run wireless. Though, as for the 10+15 coincidence -- I've seen things like that turn out to be red-herrings about 35-40% of the time with the numbers just happened to be the same as ones used somewhere else. So I wouldn't be too overfocused on the source for those 2 numbers. It would be useful if you could trace what the chain of actions was from the time you plugged it in, through 'what' actions in udev, and if it is really calling out the dhcp the way we think it is--... If nothing else, would resort to inserting print's or adding something like:

[[ -n ${DEBUG:-} || -O /tmp/debug_local ]] && { echo "(${#BASH_LINENO[@]})entering $BASH_SOURCE..." >&2; [[ -O /tmp/debug_local ]] && source /tmp/debug_local ; }

to spots in the script(s) that drive things, That way you could toggle debugging by creating a tmp file that has to be owned by you... ;-)

Sprinkled statements like that throughout my login scripts to find where hang-ups/problems were.

If you can't see stderr, append it to a tmpfile (>>/tmp/log )...

Thanks, You have been wonderful with the links and possibilities. I just haven't had a spare hour to tear it apart and pick through the logs. That will take a couple of reboots, and at present: $ uptime 19:40pm up 5 days 7:39, 2 users, load average: 0.21, 0.16, 0.24 No time for that.... ** Moment of Silence Please ** We should also take a moment of silence for 'nemesis' my trusty old AMD Athlon TBird on a Abit KT7 board w/1G that began life with SuSE 7.0 (Air), which has served as my fax server (hylafax/Avantfax) since 10.0 days and currently sports a flashy install of 11.0. Linux-raid has been through 1/2 dozen disks over the decade and a half without a data hiccup. $ cat /proc/mdstat Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] md2 : active raid1 sda7[0] sdb7[2] 221929772 blocks super 1.0 [2/2] [UU] bitmap: 0/424 pages [0KB], 256KB chunk md0 : active raid1 sda1[0] sdb1[2] 104376 blocks super 1.0 [2/2] [UU] bitmap: 0/7 pages [0KB], 8KB chunk md1 : active raid1 sda5[0] sdb5[2] 20972752 blocks super 1.0 [2/2] [UU] bitmap: 6/161 pages [24KB], 64KB chunk unused devices: <none> Though it had been bandaided with new openssl, and xz integration, bash, and other forward-ported updates, it has always kept ticking. It has experiences 2 dirty page kernel faults in the past 2 weeks indicating that a cap somewhere is beginning to fail. (I hope it is a cap on the old USR internal fax-modem and not the board itself -- which would explain the mgetty error on the first crash) They just don't make-em like they used to. Only 16 years out of service with that rig (original Antec case and power-supply as well). (proverbial handful of dirt along with a flower tossed on top of the case...) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org