| n4dir | i started the laptop, and it didn't connect to the internet. I ran "ip a", and it doesn't show the wireless device anymore. lspci -k does show it and that iwlwifi is in use | 07:58 |
|---|---|---|
| n4dir | connection/setup happened during installation, seems to be via wpasuppliciant and an entry in /etc/network/interfaces. No other network manager is involved | 08:00 |
| n4dir | i don't know what else to do. Might a kernel upgrade be the reason? | 08:00 |
| n4dir | oh, this is excalibur | 08:00 |
| brocashelm | what's the kernel? uname -r | 08:01 |
| brocashelm | does ifconfig show anything? | 08:01 |
| n4dir | 6.5.0-5-amd64 | 08:01 |
| n4dir | ifconfig also doesn't show the wireless device, like ip, only lo and eth0 | 08:01 |
| brocashelm | have you checked if you had the correct firmware installed, that wireless is enabled from the bios, etc.? | 08:02 |
| brocashelm | if yes to all of those, then sounds like a kernel problem | 08:02 |
| brocashelm | have you tried booting to a previous kernel? | 08:02 |
| n4dir | there is a "key" i can use to turn on and off wireless. To test if i hit it by accident, i hit it again, i assume then running ip or ifconfig it will show it immediatly | 08:02 |
| n4dir | ok, i will reboot to an older kernel next boot | 08:03 |
| brocashelm | the 6.x kernels have been problematic IME | 08:03 |
| n4dir | if lspci -k shows the corrct driver in use, i assume it is the correct firmware | 08:03 |
| n4dir | i am really rather bad with the firmware stuff, and with wireless too | 08:04 |
| brocashelm | just remember to check for non-free-firmware on your sources.list file | 08:04 |
| n4dir | nah, this worked until yesterday ever since installed. Nothing changed, i probably did an upgrade yesterday, but didn't pay much attention | 08:04 |
| n4dir | so as far i can tell the general setup should be fine | 08:05 |
| brocashelm | is the wifi like iwlwifi, broadcom, realtek, etc.? | 08:05 |
| n4dir | iwlwifi | 08:05 |
| brocashelm | then that is a red flag | 08:05 |
| n4dir | it is? for newer kernels? | 08:05 |
| brocashelm | intel drivers/firmware should always "just work" on linux | 08:05 |
| n4dir | might be the wireless device just died? | 08:05 |
| n4dir | uhm, i am not sure what it means if lspci shows it | 08:06 |
| brocashelm | doubtful if you can boot to an older kernel and it would work | 08:06 |
| brocashelm | this is part of why i am staying on 5.19 | 08:06 |
| n4dir | brocashelm: let me try that right away. See you in a bit | 08:06 |
| brocashelm | for daedalus | 08:06 |
| brocashelm | ok | 08:06 |
| n4dir | brocashelm: nope, the older kernel, 6.5.0-4-amd64 | 08:09 |
| n4dir | also doesn't show wlan for ip and ifconfig | 08:09 |
| n4dir | i woke up and the first thing i run into is the smartphone being broken, the next thing i run in is wireless on the laptop not working anymore | 08:09 |
| n4dir | looks as if a great day is ahead of me | 08:10 |
| n4dir | i see nothing in apt's history log which might relate to wifi | 08:11 |
| brocashelm | n4dir: i guess i meant to say 6.1 or so for an older kernel | 08:13 |
| n4dir | yeah, but on the newer kernels it seem to have worked until yesterday | 08:13 |
| n4dir | i just looked if there is an elder kernel to be found for excalibur, but it doesn't seem so | 08:13 |
| n4dir | i could add daedalus and install one that way, but i start to doubt it is the kernel | 08:14 |
| brocashelm | it doesn't hurt to try installing daedalus' kernel | 08:14 |
| n4dir | yup. doesn't hurt | 08:14 |
| brocashelm | but this doesn't surprise me much | 08:14 |
| brocashelm | before you left, i said this is why i'm staying with 5.19 | 08:15 |
| brocashelm | despite daedalus default kernel being 6.1 | 08:15 |
| n4dir | i read that you said you use that kernel on daedalus | 08:15 |
| brocashelm | oh | 08:15 |
| n4dir | or i only dreamt it, pretty confused right now. | 08:15 |
| brocashelm | nope, not a dream :) | 08:16 |
| n4dir | to me it isn't that bad, i got no problems using the cable | 08:16 |
| n4dir | still sucks running in such right after waking up | 08:16 |
| brocashelm | i was on ceres for a while, and then switched to daedalus when it went to freeze | 08:17 |
| brocashelm | seems like i picked the perfect time | 08:17 |
| n4dir | i would have staid on daedalus too, but i really wanted the newer ardour version | 08:17 |
| brocashelm | were you able to build it from source? | 08:18 |
| brocashelm | i keep backports for certain newer software if i need it | 08:18 |
| n4dir | i once did it, and it wasn't too hard, in fact it just ran through. But i prefer the binary version | 08:18 |
| n4dir | #ardour also kinda recommends against it. Well: they really recommend to use their "versions" | 08:19 |
| n4dir | so neither compile yourself, nor use the distros binary versions, but use theirs | 08:19 |
| n4dir | brocashelm: all i find after adding daedalus is 6.1 kernel, not elder, it seems | 08:20 |
| divad27182 | you said the device showed up in lspci. Did lspci -v show a kernel driver in use and kernel modules? if not, maybe you just need to modprobe | 08:38 |
| n4dir | lscpi -k did show the kernel driver in use, iwlwifi | 08:39 |
| divad27182 | did you try "ip link" ? | 08:40 |
| n4dir | after you said it, same as for ip a | 08:40 |
| n4dir | well, not the same, but it only shows lo and eth0 | 08:40 |
| divad27182 | you might try doing rmmod iwlwifi ; modprobe iwlwifi | 08:41 |
| divad27182 | and then examining dmesg output for errors | 08:41 |
| n4dir | tried that after your first comment, didn't result in anything | 08:41 |
| n4dir | oh, dmesg | 08:41 |
| n4dir | divad27182: yup, that gave a meaningful error message | 08:42 |
| divad27182 | Good. I hope it is something fixable. | 08:42 |
| n4dir | failed to load firmware and iwlwifi-6000-4 is required | 08:42 |
| n4dir | iwlwifi-6000-4 is required | 08:42 |
| divad27182 | You might try the package firmware-iwlwifi | 08:45 |
| n4dir | that is installed | 08:45 |
| n4dir | still confused why this worked until yesterday | 08:45 |
| divad27182 | did you power cycle since then? Did you run windows before linux yesterday without power cycling? | 08:46 |
| divad27182 | (odd possibility) | 08:46 |
| n4dir | no windows, and i don't know what power cycle is | 08:46 |
| divad27182 | turn off power, turn on power | 08:46 |
| divad27182 | tends to fully reset hardware | 08:47 |
| n4dir | yes, i did that | 08:47 |
| divad27182 | have you googled the error message? | 08:48 |
| n4dir | doing it right now, but not that good results, am starting | 08:49 |
| divad27182 | Well, iwlwifi-6000-4 is part of the filename. It should be in /lib/firmware/ | 08:53 |
| divad27182 | In my experience, you might need to reboot if you only just installed firmware-iwlwifi | 08:53 |
| divad27182 | Of if the iwlwifi modules is in you initramfs and the firmware is not | 08:54 |
| divad27182 | s/Of/Or/ | 08:54 |
| n4dir | i didn't just install it | 08:54 |
| divad27182 | But you did the kernel, I think you said. Check to see that either both files or neither file is in the initramfs | 08:55 |
| n4dir | /usr/lib/firmware/iwlwifi-6000-4.ucode | 08:55 |
| n4dir | No, i was thinking there might have been a kernel upgrade, but there was none | 08:55 |
| divad27182 | I take it you have the /usr/lib and /lib merge in place? | 08:57 |
| n4dir | what is the merge? | 08:58 |
| divad27182 | classically, /usr/lib and /lib are different directories. The firmware goes in /lib/firmware/ | 09:00 |
| divad27182 | A few releases back, debian concocted something to symlink the one to the other, and similarly for bin and sbin | 09:00 |
| divad27182 | simpler for new users.... | 09:00 |
| divad27182 | I won't touch it. | 09:01 |
| divad27182 | Of course, the reason for the separation is that / is a small disk, with only enough to let you mount /usr | 09:01 |
| divad27182 | and that hasn't been an issue for a LONG LONG time | 09:01 |
| divad27182 | I think Debian Buzz would actually do that | 09:02 |
| n4dir | i downloaded the older, stable, version of firmware-iwlwifi, and ip shows wlan0 again. | 09:23 |
| n4dir | what a nightmare. | 09:23 |
| n4dir | thanks brocashelm and divad27182 | 09:23 |
| divad27182 | which version is this? | 09:24 |
| divad27182 | 2021.... or 202302.. or something else | 09:24 |
| n4dir | firmware-iwlwifi_20230210-5_all.deb | 09:25 |
| n4dir | that is the elder version. | 09:25 |
| divad27182 | thank you :-) | 09:42 |
| Besnik_b | gnarface, you mention wayland the other day as an example of “merit is often determined just by how many volunteers you can wrangle”. I’m curious to read about that. Can you help any link? | 09:54 |
| spine-o-saurus | im getting some error upgrading netcat-traditional | 13:00 |
| hagbard | spine-o-saurus: Yes, there's a debian bug about it: https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1941966.html | 13:14 |
| hagbard | As a quick and dirty workaround, hardlinking the relevant file from the actual to the expected path did let me upgrade the package. | 13:15 |
| ineff | Hello everyone. | 14:29 |
| ineff | Question: have they fixed the problem with the linux-image package? | 14:30 |
| ineff | or if you prefer, is it safe to do an updated now? | 14:30 |
| rkta | It's fixed in 6.1.66, which seems to have another issue https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.67 :-D | 14:40 |
| _ds_ | Fun™ | 14:41 |
| ineff | So....this raise the question, can I safely update to kernel 6.1.0-15? | 15:03 |
| djph | Depends on whether or not the issue is in 6.1.0 ... | 15:13 |
| djph | AIUI, the issue(s) were in 6.1.65/66 ... | 15:14 |
| ineff | Is there any way to find out? | 15:31 |
| djph | read the patchnotes for 6.1.0-15 compare to 6.1.66 | 15:35 |
| ineff | thanks djph | 15:41 |
| rwp | Sometimes when there are big issues like that it is good to wait a few days or a week to upgrade. | 19:02 |
| rwp | Because you KNOW they are pushing very hard to get a fix out. Working under time stress like that is hard and it is easy to have a secondary problem. | 19:02 |
| rwp | In a week everything will have settled down. | 19:03 |
| rwp | Meanwhile I upgraded two of my canary machines and am keeping an eye on them. Looks okay to me so far. | 19:03 |
| claes | Is this the place to ask for help/support for an annoying Devuan networking issue I have? | 19:16 |
| cousin_luigi | Greetings | 19:18 |
| rwp | Good morning claes. Yes. This is the place! Please ask away. If someone knows the answer they will respond. | 19:18 |
| claes | Excellent, thank you. | 19:18 |
| rwp | Hang around a little. People come and go and there might not be an immediate knowledge source available. | 19:18 |
| cousin_luigi | I've started tinkering with devuan and every time I issue a reboot from ssh, I get asked for the root password on the system console. Which I cannot see from there. | 19:18 |
| claes | A little background: I've been running Devuan for a few years now, but I'm still a bit of a noob when it comes to Linux and the more I learn about networking the more it resembles magic. | 19:19 |
| claes | Ever since I upgraded my home Devuan server (file/media server) to Daedalus, I've been having a network issue. The server won't connect automatically to my network. It keeps asking for a DHCP lease (I think is the term) on the wrong subnet. It asks on 192.168.1.1 but my subnet is 172.17.2.1 | 19:21 |
| claes | In the past I've worked around it by unplugging the network cable, rebooting the machine, logging in and then run "ifup eth0" which would report back an error (unable to bring up interface), but it worked for some reason | 19:23 |
| claes | After the latest updates, that doesn't work either... | 19:23 |
| claes | I'm stumped. I've tried setting /etc/network/interfaces to a static IP address (address 172.17.2.7, netmask 255.255.255.0 gateway 172.17.2.1) but that doesn't work (I'm guessing it's a DHCP<->Static IP conflict in the router?). | 19:26 |
| claes | Interestingly, when running "sudo service networking restart" I get this: "DHCPREQUEST for 192.168.1.7 on eth0 to 255.255.255.255 port 67" followed by repeated "DHCPDISCOVER" requests. | 19:28 |
| claes | 192.168.1.7 was the IP address the server used to have before I changed the network range. Anyone know where the server gets this old address from and if I can change it to my new network range? | 19:29 |
| rwp | cousin_luigi, At install time did you set up an encrypted file system? Using LUKS? If so that's pretty much the way it works. | 19:33 |
| rwp | I have not used it myself yet though so no first hand experience with it. | 19:33 |
| rwp | If this is a remote system look at the "mandos" package and associated system. It's designed to work with remote encrypted file systems. | 19:33 |
| cousin_luigi | rwp: No. But the problem is intermittent. | 19:34 |
| rwp | Next time it asks for a password, copy-paste the exact text off to a file to save it so that you can share it with us. | 19:34 |
| cousin_luigi | Now it seems to have disappeared. I'm hacking away at default packages to recreate my own custom debian from 15 years ago, so who knows what I'm doing. But that request came quite early. Before disabling apparmor, that is. | 19:35 |
| rwp | claes, I am staring at your problem description and trying to figure it out. It's still early here for my brain and I will need a moment of staring. | 19:35 |
| rwp | claes, Could it be a sudo password prompt? Or a gtksudo(spelling?) prompt for the graphical side? | 19:36 |
| claes | no worries. It's just a home server and I do have physical access to it, so it's not hair-on-fire. | 19:36 |
| rwp | Wups, I meant s/claes/cousin_luigi/ on that last one! | 19:36 |
| cousin_luigi | rwp: no, console. It's a headless system. | 19:37 |
| cousin_luigi | It's the sort of query one sees at runlevel 2 when trying to rescue the system IIRC | 19:38 |
| rwp | claes, I presume you have one wired network interface. But then if it is listed in /etc/network/interfaces then the ifupdown system will manage it from there forward. OTHER systems such as Network-Manager should be ignoring it. | 19:38 |
| rwp | But I feel that there must be multiple network class managers fighting with each other there. | 19:38 |
| rwp | If you do a "ps -efH | grep dhclient" do you see a dhclient program running? Hopefully not since you have configured a static IP address. | 19:38 |
| rwp | That would be just a clue for a symptom of the problem. And I have sometimes on DHCP configured systems had multiple dhclient programs running as a bug case and that's also bad. But you want a static IP configured. | 19:39 |
| rwp | Can you https://paste.debian.net/ your /etc/network/interfaces file for sharing? And also check that you don't have a /etc/network/interfaces.d/* other file that is fighting with it? | 19:40 |
| claes | I should clarify that I removed the static IP setting once I realized it didn't work. It's back to dhcp, but I'll find the output for you. | 19:41 |
| cousin_luigi | rwp: (including ctrl-D) | 19:41 |
| rwp | As a different problem that might also be related for each of your DHCP configured systems. Might it be possible that you have TWO or MORE DHCP *servers* on your LAN? That would match a possible way to have sometimes 172.17.2.* and sometimes 192.168.1.* because sometimes getting a dhcp address from one and sometimes a dhcp address from the other. | 19:41 |
| rwp | I have seen people accidentally attach a router to the network, it has a dhcp server enabled, it might not have an upstream WAN connection so when connected to that rogue one there probably is no route out to the Internet. | 19:43 |
| rwp | That seems the most plausible explanation that fits to me right now. Until you tell me new data. I would install "dhcpdump" program, run it in a terminal, and let it tell you the details of the DHCP protocol exchange. There should be good information such as MAC ethernet hardware addresses of the server that is offering the rogue dhcp address. | 19:44 |
| rwp | cousin_luigi, That sounds like your system is booting up into single-user-mode not multi-user-mode. At single user mode there is usually a root password prompt like that. | 19:46 |
| rwp | cousin_luigi, Is your system a default sysvinit system? Check /etc/inittab for "id:2:initdefault:" if that says something other than 2 then that would be a possible reason. | 19:47 |
| cousin_luigi | rwp: Indeed. But why would it do that on its own after a reboot? | 19:47 |
| claes | Output: | 19:47 |
| claes | claes@odin:/etc/network$ ps -efH | grep dhclient | 19:47 |
| claes | claes 18343 11753 0 11:42 pts/0 00:00:00 grep dhclient | 19:47 |
| claes | root 15215 1 0 11:11 ? 00:00:00 dhclient -4 -v -i -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases -I -df /var/lib/dhcp/dhclient6.eth0.leases eth0 | 19:47 |
| cousin_luigi | rwp: anyway it's not doing it anymore. I have bigger fish to fry atm, but I'll keep that in mind. | 19:48 |
| rwp | claes, Be careful pasting into any libera chat channel. Always use a pastebin. There is a global Liber.Chat wide bot that will kick anyone who pastes too much. It's considered abuse. | 19:48 |
| claes | Oh, sorry. | 19:48 |
| rwp | If you get kicked for it please just join back in again. It's usually just a kick the first time and not an auto-ban. Just join back in if that happens to you. | 19:48 |
| rwp | That ps listing lists only one dhclient and it looks okay. Configured for IPv4 only. | 19:50 |
| claes | Thanks. I really didn't know. I think this is only the second time I've used IRC for anything. | 19:51 |
| rwp | No worries! The journey of 10,000 miles begins with the first step. We all start out at the beginning and proceed onward from there. I just wanted to let you know the problem. | 19:51 |
| claes | paste of the /etc/network/interfaces: https://paste.debian.net/1300816 | 19:53 |
| rwp | The other thing I would do is review /var/log/syslog and look at the dhcp exchanges logged there. That would be useful. Maybe "grep -i dhcp /var/log/syslog | less" | 19:53 |
| rwp | That's a perfect paste! Excellent. Looks perfect. Look in /etc/network/interfaces.d/* for any additional files. If none there that is good. | 19:54 |
| claes | and /etc/network/interfaces.d/ is empty so there shouldn't be a conflict. | 19:54 |
| rwp | Side comment: I know there is a bunch of old documentation with both address and netmask but these days we prefer to see 172.17.2.7/24 using the combined CIDR format rather than the separate netmask. It's the same thing of course, no difference, but we just like and prefer the more conside CIDR format for most things these days. | 19:55 |
| rwp | This is all making me think you have a rogue dhcp server on your LAN. Look through /var/log/syslog for logs of the dhcp exchanges. I am going to be confident that is the problem, right up until you say you have looked extensively and it can't be that, but it fits the problem. | 19:56 |
| claes | Okay. This is just what the intertubes yielded... | 19:56 |
| claes | Okay, will do. | 19:56 |
| rwp | Also I find "dhcpdump" useful to debug these things. It opens a "promiscuous mode" connection to the network and prints out every dhcp exchange it sees. Useful for debugging. Pretty sure it shows the hardware address. And from that you should be able to track down the rogue offender. | 19:57 |
| rwp | I would unplug all of the extra cables from the network switch and things will start working. Then could plug them in one at a time until you find which wire contains the offending server. | 19:58 |
| rwp | The "arp -an" command is also useful too. | 19:59 |
| rwp | I have a skillet heating up calling my name. BBIAB. | 19:59 |
| claes | Okay, here's an excerpt of /var/log/syslog. It goes on like this for a lot longer, but this was all that was saved (had an encoding issue!?). https://paste.debian.net/1300818 | 20:10 |
| claes | Looks like the server and router play "you're it" to me... | 20:11 |
| gnarface | Besnik_b: well it's not really a support topic, it's more appropriate for #devuan-offtopic | 20:36 |
| gnarface | i don't have any links off the top of my head but i'm sure they shouldn't be hard to find if you look for statements made by the wayland creators themselves | 20:37 |
| Besnik_b | I see… thank you! | 20:37 |
| Besnik_b | I’ll check around | 20:37 |
| rwp | claes, That's definitely "not good" there. Normally we would see the DHCPREQUEST and DHCPACK in a recurring cycle of good. But why is it DHCPDECLINE'ing it immediately afterward? That's flummoxed me. I can't imagine why. | 20:45 |
| rwp | What is your dhcp server? Is that your house router and/or modem box? If it is then would start by rebooting it. Those are not always the most robust of systems. | 20:46 |
| claes | Yeah, DHCP server is an old TP-Link router. I can try rebooting it, but I really don't think that's the issue. BRB. | 20:48 |
| rwp | And then I would log into the admin panel of the router/modem and review everything. Because you said 192.168.1.1 was handing you an IP address earlier. If you don't see anything that looks like 192.168.1.* then I still think there must be yet another server somewhere with 192.168.1.* configured. | 20:48 |
| claes_ | Okay, I'm back. I'm sorry, but I may not have been clear enough on the IP addresses. The Server initially requests an IP address on an invalid subnet (192.168.1.1). It never receives one, since there's nothing at that address. | 20:55 |
| claes_ | That seems to somehow be stuck in a loop. Only unplugging the network cable fixes that. A reboot after unplugging makes it give me a login screen. Plugging in the cable and then running "ifup eth0" used to fix it but no longer does. | 20:57 |
| claes_ | The server is the only thing trying to do anything on 192.168.... | 20:57 |
| claes_ | It's getting the server to, I suppose, accept an IP address in the 172.17... range that's the issue. | 20:58 |
| claes_ | I don't know why it keeps requesting a) an old now invalid IP address in the first place and b) won't accept an IP address from the new range. | 20:59 |
| claes_ | Oh and the router has nothing with 192.168.1 in it. Here are the DHCP settings: https://paste.debian.net/1300822. Please note line 11 has radio buttons on it that aren't showing in the paste, "enabled" is selected. | 21:03 |
| claes_ | There's also a section with reserved addresses, they're all in the 172.17... range. | 21:05 |
| djph | A host can /request/ an IP on any subnet (usually the most recent IP it had); it's up to the DHCP server to respond to the broadcast and tell it the proper address to use | 22:08 |
| rrq | when dhclient starts, it reads /var/lib/dhcp/dhclient.leases to find some prior IP to ask about, and then it writes that file upon getting an IP. | 22:14 |
| rrq | and, with allow-root in the /etc/network/interfaces of the initrd, then it'll use that file from the initrd first, and first write it within the unpacked inird before writing it on disk upon a later re-request. | 22:27 |
| rrq | "allow-hotplug" rather | 22:27 |
| rrq | (but ideally initrd shouldn't have any /var/lib/dhcp/dhclient.leases) | 22:31 |
| rwp | Something as yet unexplained is still happening. We are not yet to root cause. | 22:40 |
| fsmithred | a file in /etc/network/interfaces.d/ ? | 22:47 |
| fsmithred | or something in /etc/dhcp/dhclient.conf? | 22:48 |
| rrq | duplicate dhclient? eg one started as service in addition to the one started by ifup? | 22:50 |
| claes__ | I just edited /var/lib/dhcp/dhclient.eth0.leases and /var/lib/dhcp/dhclient.leases to use 172.17.2.7 instead of 192.168.1.7, but to no avail (I picked up those 2 files as they were referenced when running ifup)... | 22:51 |
| claes__ | The server now requests 172.17.2.7 (sent to 255.255.255.255 on port 67), but still doesn't connect | 22:52 |
| rrq | the server provides good gateway? | 22:53 |
| rrq | ah i guess you meant "the client requests" ? | 22:54 |
| rrq | does it get a lease? | 22:55 |
| claes__ | I don't think so. It doesn't show up as client on dhcp server (router) and I can't connect to anything from the server. "ip addr" says "2 eth0: <NO CARRIER, BROADCAST, MULTICAST, UP> mtu 1500 qdisc fq_code1 state DOWN group default qlen 1000 | 22:57 |
| rwp | "NO CARRIER"? No ethernet link? Run "ethtool eth0" on it and see what the last line says. | 22:58 |
| claes__ | (cont.) "link/ether {MAC Address here} brd ff:ff:ff:ff:Ff:ff" | 22:58 |
| rrq | "NO CARRIER" ... is the cable good? | 22:58 |
| claes__ | link detected: no | 22:58 |
| claes__ | I hope so... Don't tell me it's the goddarn cable... | 22:59 |
| rrq | unplug + plug in... both ends | 22:59 |
| rwp | If there is no link then you should not be seeing a light on the RJ-45 port either. Nothing would work then. But you were previously getting DHCPDECLINEs so it must have been connected before. This is a new problem. | 22:59 |
| rrq | right, and then it may need "ifdown --force eth0" to reset client state | 23:04 |
| claes__ | I can't make sense of it. I thought I might have a hardware issue, as neither the physical ethernet port (eth0) or the switch lit up. Changing cables back and forth (and trying different ports on the switch) haven't changed it. | 23:07 |
| claes__ | But now, running "ethtool eth0" it says "Link detected: yes" where it said no the first time I ran it. | 23:07 |
| claes__ | Should I run "ifdown --force etho"? | 23:08 |
| claes__ | *eth0 | 23:08 |
| rrq | yes good to do.. sounds like your cable or plugs are unreliable | 23:08 |
| claes__ | alright, done. | 23:09 |
| claes__ | "ifup eth0"? | 23:09 |
| rrq | yes | 23:10 |
| claes__ | Nothing makes sense. Here's a paste of what's (still) going on. It keeps declining the IP address, yet it somehow works now. I just ssh'd into the server and firefox on the server connects... | 23:18 |
| claes__ | https://paste.debian.net/1300838 | 23:18 |
| claes__ | So the workaround that I used suddenly works again. I guess I need to replace the cables and maybe switch ethernet ports? | 23:20 |
| claes__ | I swear, computer networking requires just the right kind of incantation on the third night after a new moon... | 23:22 |
| gnarface | claes__: make sure you don't have any Windows boxes or other such things accidentally providing a conflicting DHCP broadcast, then consider switching to isc-dhcp-client | 23:24 |
| blockhead | you must appease the machine spirits to get network to work ;) | 23:24 |
| claes__ | There are no Windows boxes on the network right now (wife is at work, when she gets home it'll be different). I use Linux Mint on my laptop and my phone is Android. That's all that's on the LAN right now. | 23:26 |
| claes__ | Both laptop and phone use wifi, server is hardwired (via a switch). I have a Synology NAS that's powered off on the switch as well. | 23:27 |
| gnarface | is the wifi router a separate router? | 23:27 |
| rrq | your docker0 interface has 172.17.0.1/16 .. does it have a dhcp server? | 23:28 |
| claes__ | No, it's just an old TP-Link ADSL modem/router (I live waaay out in the countryside.) | 23:28 |
| claes__ | I don't know about the docker, it just works, somehow. I mostly use linuxserver.io's images and Docker Compose. | 23:29 |
| gnarface | most the time this type of behavior is caused by two DHCP servers fighting, but i've also occasionally seen compatibility issues with the default dhcpcd that the alternate, reference implementation, isc-dhcp-client doesn't have | 23:29 |
| rrq | well, any 172.17.0.0/16 packets would go to it | 23:29 |
| gnarface | yea i suppose a weird routing issue could do it too | 23:30 |
| rrq | what does "ip r" (or "ip route show") tell ? | 23:30 |
| rrq | and "brctl show" is good to, to see the bridging set up | 23:31 |
| claes__ | one moment. Need to shuffle usb stick around and copy/paste output... | 23:31 |
| claes__ | brctl gives "command not found" | 23:32 |
| rrq | hmm but br-660db2c8aee6 and br-89556810fc0e are bridges? | 23:33 |
| claes__ | https://paste.debian.net/1300840 | 23:34 |
| rrq | I think you would be happier separating the eth0 and docker0 networks | 23:37 |
| claes__ | So move docker to use eth1, somehow? | 23:38 |
| claes__ | I mean physically separate them? | 23:38 |
| claes__ | I do have a second ethernet port on the server (plus an IPMI that I've never used) | 23:39 |
| rrq | no, change it's setup to use /24 rather than /16 | 23:39 |
| rrq | then 172.17.0.* would be docker0 net and 172.17.2.* would be eth0 net | 23:40 |
| claes__ | But isn't that what it's doing now? Docker0 is listed as 172.17.0.1/16 while eth0 is 172.17.2.1/24? Those are tw | 23:42 |
| claes__ | Ooooh, no, /16 is a bigger net than /24... So eth0 is practically a subset of docker0 as it stands? | 23:43 |
| rrq | yes, docker0 gets 172.17.*.* packets | 23:43 |
| rrq | yes | 23:43 |
| claes__ | Gotcha! | 23:43 |
| gnarface | mystery solved? | 23:43 |
| claes__ | Maybe? I don't know... | 23:43 |
| gnarface | seems possible that you had broadcast packets getting where they don't belong... they do tend to do that | 23:44 |
| rrq | well, the more specific route should apply, but there may be some race during setup | 23:44 |
| rwp | I just saw the 33 network devices in the paste and went, whoa, that's a lot of network devices. | 23:44 |
| claes__ | Okay. So, next idiot question. How do I change docker0 to /24 instead of /16? | 23:44 |
| gnarface | subnet mask 255.255.255.0 | 23:45 |
| gnarface | sorry, dunno docker specifics | 23:45 |
| rrq | I guess there is some docker config files somewhere? | 23:45 |
| claes__ | I'll go look at some Docker documentation, it's got to be in there somewhere. | 23:45 |
| rwp | I don't do anything with docker but it MUST but wherever docker configures its address right now. Wherever that is. | 23:46 |
| claes__ | Thanks so much for your help! The docker0 thing may or may not be the right answer, but it's definitely worth looking into (and cleaning up). | 23:47 |
| rrq | an I wonder how one might see bridge port setup without brctl? | 23:47 |
| rwp | If nothing else at least temporarily stop its (docker's) operation because it certainly seems to be the problem. | 23:48 |
| rrq | I would install bridge-utils for brctl of course :) | 23:48 |
| claes__ | Dunno.. https://www.man7.org/linux/man-pages/man8/brctl.8.html says "brctl" is obsolete... | 23:48 |
| gnarface | i would also recommend installing bridge-utils | 23:48 |
| rrq | (those happy hackers that must "deprecate" anything they are not using themselves) | 23:49 |
| claes__ | Now that I can access the server, I can install dhcpdump as well. You know, for next time I have to come asking you guys for help. | 23:50 |
| claes__ | Alright, thanks again for the help. I'm out (until next time)! | 23:51 |
| rwp | Looking at the "bridge" command and I can't see how to duplicate "brctl show" there. | 23:51 |
| rwp | The man page is a good reference tool but really poor at being a tutorial. | 23:52 |
| rrq | hmm "bridge" is a protocl family for "ip" (??) | 23:55 |
| rrq | like inet and inet6 (and "mpls" and "link"... peculiar concept structure) | 23:56 |
| gnarface | i was under the impression that it worked at a lower level than that, but i could be wrong | 23:58 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!