IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 19 March 2019 (all times are UTC)
| 00:27 | enaut[m] has left IRC (enaut[m]!enautmatri@gateway/shell/matrix.org/x-fzxqqskyorbhseco, Read error: Connection reset by peer) | |
| 00:36 | enaut[m] has joined IRC (enaut[m]!enautmatri@gateway/shell/matrix.org/x-sdbyyprcsdwiwdmr) | |
| 02:14 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 272 seconds) | |
| 02:33 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
| 03:39 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 246 seconds) | |
| 03:58 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
| 06:57 | kjackal has joined IRC (kjackal!~quassel@2a02:587:3119:ef00:39ef:42dd:f5e8:3018) | |
| 07:51 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 08:52 | <vlt> alkisg: Hi!
| |
| 08:52 | My strange TFTP problem returned.
| |
| 08:53 | I have more details, am quite certain that it's not LTSP's fault but have no idea idea what casues this.
| |
| 08:54 | *causes
| |
| 08:55 | The problem affects three clients now that are all in the same part of the building, the same ethernet "segment". And: They boot from three different LTSP servers :hm:
| |
| 08:57 | Our DHCP hands out their respective IP addresses just fine and tells them where to continue, they show "Trying to load pxelinux ..." or "Loding vmlinuz ...", then take up to 10 or 12 minutes and then continue just fine.
| |
| 08:57 | I measured the network speed (just with nc) and there are no problems at all.
| |
| 08:58 | Any idea what could happen there?
| |
| 09:03 | <alkisg> !tftp
| |
| 09:03 | <ltsp> tftp: Here's a page to help you troubleshoot TFTP problems in Ubuntu: https://help.ubuntu.com/community/UbuntuLTSP/Troubleshooting/TFTP
| |
| 09:03 | <alkisg> There's a command there to fetch things from tftp
| |
| 09:04 | Try to fetch the kernel again AFTER the client boots, to measure specifically tftp speeds
| |
| 09:35 | <vlt> alkisg: Thank you!
| |
| 09:59 | On clients that finally managed to boot I used the following test command from that wiki page: `time tftp 192.168.1.9 -v -m binary -c get /ltsp/i386/pxelinux.0`
| |
| 10:00 | It's hard to recognize speed problems with that small file so I then requested initrd.img which is 16 MB.
| |
| 10:01 | On normal clients that file gets loaded in around 1 s, that matches the network bandwidth of 100 Mbit/s.
| |
| 10:02 | On one of the affected machines I got this: "Received 16283145 bytes in 605.1 seconds [215279 bit/s]"
| |
| 10:02 | Damn.
| |
| 10:03 | I watched the transfer using iftop and that speed was constantly around ~220 kBit/s.
| |
| 10:04 | But remember: sending other TCP/IP packets to and from that client now works just fine.
| |
| 10:04 | What could cause such a bandwidth limitation for TFTP transfers for that specific ethernet segment?
| |
| 10:21 | <alkisg> vlt: firewall, blocking UDP traffic, bad switches that have issues with UDP etc
| |
| 10:37 | <vlt> I can rule out a firewall. It's all local. And I think that would affect the other clients similarly.
| |
| 10:37 | Sounds more like a bad ethernet component, yes.
| |
| 10:38 | <alkisg> Ah, I've also seen bad linux drivers causing issues. That could e.g. be worked around by changing the MTU to 1492.
| |
| 10:38 | Try exchanging two clients, a good and a bad one
| |
| 10:38 | If they continue the same way, you'll make sure that switches, cabling etc are not involved, just bad drivers
| |
| 10:40 | At another case, cabling issues appeared with a realtek card, while swapping it with intel didn't cause issues, as intel was smart enough to detect the cabling problems and switch to 100 mbps instead of gigabit
| |
| 10:40 | So do the exchange part to be 100% sure that it's not switches/cables, before you start playing with MTUs and other driver parameters.
| |
| 10:46 | <vlt> Three different clients booting from three different TFTP servers (Ubuntu 12.04, 14.04 and 16.04/amd64) but all within the same part of the building more and more sounds like a bad ethernet switch to me.
| |
| 10:47 | But I'll take a working client there and see.
| |
| 10:53 | <alkisg> vlt: I've also seen switches that misbehaved because they were not reset for months. Do try resetting them before throwing them away...
| |
| 10:54 | They do have software running, even if it's not a full OS, and it still can get crashes and erratic behavior at times
| |
| 12:24 | spaced0ut has left IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut, Ping timeout: 246 seconds) | |
| 12:33 | Faith has joined IRC (Faith!~Paty_@unaffiliated/faith) | |
| 12:58 | spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut) | |
| 15:22 | Natureshadow has left IRC (Natureshadow!45d1515d22@commu.teckids.org, Remote host closed the connection) | |
| 16:58 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 20:12 | <alkisg> Hyperbyte: can we try to allow unregistered users again? I don't remember how to unset the flag...
| |
| 20:22 | <||cw> mode -r I believe
| |
| 20:22 | +r sets is, -r removes it
| |
| 20:28 | ChanServ sets mode: +o Hyperbyte | |
| 20:28 | Hyperbyte sets mode: -r | |
| 20:28 | Hyperbyte sets mode: -o Hyperbyte | |
| 20:42 | <alkisg> ty both
| |
| 21:21 | Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving) | |
| 22:52 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection) | |