dan9er[m] | Touchscreen doesn't work either, the way is to boot live image in `toram` mode, unplug the usb, then plug in usb keyboard | 00:01 |
---|---|---|
dan9er[m] | It sucked | 00:02 |
rwp | Sounds like it. Truly sounds awful. | 00:02 |
dan9er[m] | Anyway i'll try live image a bit later and let you know | 00:02 |
dan9er[m] | Actually before I do that, lemme try booting with default kernel and testing that | 00:05 |
drizzt | made an image for the surface, which should be more functionnal than what you seem to have | 00:48 |
drizzt | gonna check if I still have it | 00:48 |
dan9er[m] | Doesn't work on vanilla kernel 5.10.0-18 | 01:15 |
dan9er[m] | Alright flashing live boot USB | 01:15 |
joerg | https://www.reddit.com/r/SurfaceLinux/comments/nkhke3/comment/gzdbip0/ >>Surface has a custom HID firmware which Windows doesn’t even come by default. << *headdesk* | 02:19 |
gnarface | dan9er[m]: wait, does ping work if you're running it as root? | 02:22 |
dan9er[m] | gnarface: Nope | 02:35 |
joerg | hmmmm https://github.com/linux-surface/spi-hid | 02:35 |
joerg | >>Linux kernel driver for HID over SPI<< | 02:35 |
dan9er[m] | quite #devuan-offtopic lol | 02:36 |
drizzt | yep, I still have the files/images and a script to flash | 02:37 |
drizzt | so if you're interrested, tell me | 02:38 |
drizzt | could create a liveboot and send it, or send all the files (about 600Mb) | 02:41 |
drizzt | for the surface, woth kernel 5.0.9 | 02:41 |
drizzt | with | 02:41 |
dan9er[m] | rwp: Same problem on live image. Made a strace on that as well: https://hastebin.com/ukonuyerar.strace | 03:26 |
dan9er[m] | Wait, I used Devuan's live image, apparently Refracta is it's own thing? | 03:28 |
buZz | refracta is a distro based on devuan, a different one, yes | 03:28 |
gnarface | devuan's live image is also made with refracta though | 03:28 |
gnarface | but now i'm starting to really suspect the router | 03:29 |
dan9er[m] | I recall it working for a little bit on this router before DNS died | 03:30 |
dan9er[m] | Before I was on a different router at a different location and that worked | 03:31 |
gnarface | i wonder if it would magically start working if you ran the dns queries through a ssh tunnel to another site | 03:32 |
dan9er[m] | gnarface: huh? how would I do that | 03:34 |
gnarface | tutorials on ssh tunneling shouldn't be too difficult to find | 03:36 |
gnarface | a VPN would also work | 03:36 |
gnarface | the important part is having a remote machine you have admin access to | 03:36 |
buZz | why not just use 8.8.8.8 | 03:39 |
buZz | or whatever dns your own isp has | 03:39 |
gnarface | that's what he's doing | 03:39 |
dan9er[m] | buZz: Tried that, nothing works | 03:39 |
dan9er[m] | gnarface: If it's the router, why isn't dig(8) affected? | 03:40 |
gnarface | you could probably get dig to choke too | 03:40 |
buZz | dig ibm.com @8.8.8.8 works? | 03:41 |
dan9er[m] | how tho | 03:41 |
gnarface | dan9er[m]: dns has <b>3</b> main types of data transfers, and to have full client functionality you need at least two of them, and the hypothetical issue here would be that only one of them is working due to partial blockage (for example maybe you can get tcp to port 53 but not udp) | 03:42 |
gnarface | heh, woops, meant 3, been typing on slashdot too much | 03:42 |
buZz | lol | 03:42 |
dan9er[m] | buZz: `$ dig ibm.com @8.8.8.8` works, but not `$ ping ibm.com` | 03:44 |
dan9er[m] | gnarface: cool, how do I force dig to use 1 of those 3 | 03:44 |
gnarface | i forget, though i do have a weird recollection that a bug like this had something to do with an upgrade busting a PAM config too | 03:45 |
buZz | icmp not routed? :) | 03:45 |
buZz | whats this router? | 03:45 |
gnarface | dan9er[m]: oh, make sure dnsmasq isn't running while you're testing this too, because it can cache bad upstream states | 03:46 |
dan9er[m] | It's not running, but I purged dnsmasq-base for good measure | 03:50 |
dan9er[m] | bruh i just ran `# apt update` and it resolved domain names just fine | 03:54 |
dan9er[m] | ...at this point I might just install wireshark | 03:59 |
gnarface | worth a try | 04:02 |
gnarface | tcpdump was easier for me to figure out but ymmv | 04:03 |
dan9er[m] | `# tcpdump -nvvv udp port 53`: https://hastebin.com/ijatawirot.txt | 04:32 |
dan9er[m] | ^ from running `$ ping example.com` | 04:33 |
dan9er[m] | Nothing on TCP | 04:33 |
dan9er[m] | OH I know why apt works... I have everything on there going through tor. Answers your tunneling question gnarface | 04:37 |
dan9er[m] | ...who tf is sending a DNS lookup of my hostname | 04:40 |
dan9er[m] | I'm gonna continue this tomorrow | 04:49 |
dan9er[m] | I hope someone can grok that tcpdump paste | 04:50 |
rwp | dan9er[m], So apt-get works? But it would need to do DNS lookups the same as other things. So strange. | 07:03 |
rwp | And the live boot also did not work? Like gnarface I suspect the router. | 07:03 |
dan9er[m] | Because I have all my sources going through Tor | 07:03 |
dan9er[m] | DNS is being tunneled through tor | 07:03 |
rwp | That would reinforce that it is your router that is hating upon you. | 07:04 |
rwp | Can you take your Surface to some other network? Try it at a coffee shop, library, friend's place or something? I suspect it would work on a different network. | 07:04 |
rwp | If you have another system that you can log into elsewhere then you can tunnel everything including DNS through the remote system. | 07:06 |
rwp | No root/admin needed on the remote system. I like "sshuttle" for that purpose. | 07:06 |
rwp | For example if my local LAN is 192.168.0.0/24 is the local LAN then: sshuttle -v -x 192.168.0.0/24 -r 93.184.216.34 0/0 | 07:07 |
rwp | The -x excludes destinations on the local LAN. The -v is verbose. The -r is the remote system to ssh into and 93.184.216.34 is example.com for the example. The 0/0 is proxy tunnel all other IP networks. | 07:08 |
rwp | That will run in that terminal window until you interrupt it with Control-C. | 07:08 |
rwp | It needs sudo to get root on the local system only. | 07:09 |
rwp | While running it will tunnel all to the remote system. | 07:09 |
rwp | I use this all of the time when I am working from client sites so that I can research on the web avoiding their corporate filters that I am going to unapproved sites. | 07:10 |
buZz | nice tip rwp | 08:19 |
u-amarsh04 | still having problems with kexec-tools and Debian maintainer doesn't seemed to have closed bug reports similar to what I experienced | 17:51 |
dan9er[m] | rwp: I have my router control panel open, what am I looking for | 19:02 |
rwp | dan9er[m], No idea. Something seems broken. But there are many ways for things to fail but only one correct way for them to work. | 19:03 |
rwp | This will sound awful but you will be looking for something that causes it to behave badly. What might that be? No idea. | 19:04 |
rwp | Have you considered trying your device on a different network? | 19:04 |
rwp | Honestly I am probably stuck not thinking about some particular detail in your environment which is the explanation for the oddities. | 19:07 |
dan9er[m] | Haven't been able to get to one yet | 19:07 |
rwp | It will be something that I would never consider doing but has likely become common place for other people. | 19:07 |
rwp | For example I did not realize that DNS for TOR went out through TOR and so your apt source.list queries work. | 19:09 |
rwp | Is your router a Devuan system too? Or one of the consumer mass market devices? | 19:10 |
dan9er[m] | It's a Hitron | 19:11 |
rwp | A consumer mass market device. I know nothing about it. Each type can be uniquely different. But most have similar features. | 19:12 |
dan9er[m] | IDS and IDENT is blocked on router firewall | 19:14 |
rwp | That sounds typical. I block those too. | 19:14 |
dan9er[m] | There's a diagnostics page, where I can ping and traceroute from the router | 19:16 |
rwp | Actually a better way of saying it is that I block everything by default and only allow a list of things and ident is not one of those things. | 19:16 |
rwp | As a summary of the reports about your problem is that IP addresses always work. Right? | 19:18 |
dan9er[m] | Yep | 19:18 |
rwp | DNS lookups work such by dig directly but fail when done by other utilities going through the standard libc stuff. Right? | 19:18 |
dan9er[m] | Yes | 19:19 |
rwp | However your /etc/resolv.conf contains normal 3rd party nameservers (9.9.9.9) and those are blocked timing out. | 19:19 |
rwp | Just very odd! | 19:19 |
dan9er[m] | I can ping nameservers directly | 19:20 |
dan9er[m] | `ping 9.9.9.9` works | 19:20 |
rwp | If it were me at this point I would be forced into trying random stuff hoping that something would be a clue that would make things work. | 19:20 |
dan9er[m] | Did you see my tcpdump paste yet? | 19:20 |
rwp | For example instead of specifying nameservers directly I would try... Installing a local caching nameserver (which is my standard operating practice) such as unbound. | 19:21 |
rwp | I looked at your tcpdump last night. Looked like things were timing out. | 19:21 |
rwp | But you might *try* something, no expectation that it will work, but maybe different error messages. I would install unbound, set /etc/resolv.conf to 127.0.0.1 to use it. Then see if it is happy that way. Or look in the /var/log/syslog file for errors reported by unbound. | 19:22 |
rwp | I have always used BIND (Berkeley Internet Name Daemon) mostly. But unbound (you see the play on words there) is a newer and in many ways simpler local nameserver that has been slowly gaining use. | 19:23 |
dan9er[m] | libunbound8 is installed wut | 19:23 |
rwp | That's a client library only. Used by other things. "apt-get install unbound" | 19:24 |
dan9er[m] | Installed, lemme look up how to configure | 19:30 |
rwp | The defaults for everything should be good. Just ensure it was started at installation time. "ps -ef | grep unbound" | 19:31 |
rwp | Then are you running "resolvconf"? Or Network-Manager? Honestly the best thing might be to reboot if so as those write and manage /etc/resolv.conf | 19:32 |
rwp | But if not then edit /etc/resolv.conf and set one line "nameserver 127.0.0.1" only so that libc programs will look to the local unbound daemon. | 19:32 |
rwp | And that is all that is needed. | 19:32 |
rwp | Look in the system log /var/log/syslog for messages from unbound that would indicate errors. | 19:34 |
fsmithred | I have unbound and network-manager installed and the only way it works for me is to make resolv.conf immutable | 19:37 |
fsmithred | otherwise n-m oversteps its bounds. | 19:37 |
* rwp hates network-mangler | 19:38 | |
fsmithred | sometimes I do, too. But it makes life a little easier on the laptop that goes with me to different places. | 19:39 |
fsmithred | afk bbl | 19:40 |
Ryushin | I remember reading the meeting log notes about someone who created a program that would make a SysV init script from the systemd unit files. | 19:48 |
dan9er[m] | rwp: Using unbound works! | 19:49 |
Ryushin | I don't like that some software programs have pretty much only gone to supporting systemd when they had init scripts in their packages before. Bareos and NTOPNG are the latest to actually remove the SysV scripts from their packages when it worked fine in the past. | 19:50 |
dan9er[m] | lol that's so weird, libc DNS stops working on this network for whatever reason | 19:50 |
Ryushin | Opening up tickets asking them to add them back and they pretty much told me to go pound sand. | 19:50 |
Wonka | Ryushin: there's orphan-sysvinit-scripts - maybe those sysv scripts are there now? | 19:51 |
Wonka | (but yes, grinds my gears too) | 19:52 |
Ryushin | Wonka: Nope. Bareos told me to have them put it in there. It's just stupid in my opinion that they are orphaning them on purpose. | 19:52 |
Wonka | shows how much Debian's "we don't enforce any init system" is really worth | 19:53 |
Ryushin | I've been using Devuan since Jessie. Heck, it's only because of Devuan that I'm not on FreeBSD right now. But it's getting harder and harder to stay with Devuan if 3rd party packages don't work. | 19:53 |
rwp | dan9er[m], Your last about thing stopping working... Did unbound work then stop? | 19:54 |
Ryushin | Wondering if maybe Devuan should include these packages in their distro. | 19:54 |
Ryushin | I'm working on fixing the Bareos SysV files as their daemons don't create a PID any longer. | 19:54 |
Wonka | .oO( a pid file, likely. the pid itself is chosen by the kernel. ) | 19:55 |
dan9er[m] | rwp: ??? Unbound works, i'm good now. *direc tvia libc* is was wasn't working so we "replaced" with unbound | 19:56 |
dan9er[m] | Will I need to do extra config to have unbound do DNSSEC? | 19:56 |
rwp | unbound will handle DNSSEC okay with default settings. | 19:57 |
rwp | DNSSEC handling is probably the strong point of unbound. | 19:58 |
rwp | As fsmithred noted network-manager has a history of mangling /etc/resolv.conf so if you manually set that up and things stop working look there first. | 19:59 |
Wonka | "chattr +i" may help there... that does leave some programs a little irate though. | 19:59 |
rwp | It's crass but I have done the immutable thing too in order to keep NM from breaking things. | 20:00 |
Wonka | I actually used it to stop alsa from overwriting my asound.state | 20:02 |
Wonka | on shutdown it would try to save the state... | 20:02 |
rwp | Also let me note that connecting to "captured portal" networks (Example Starbucks) can sometimes be trouble in a secure DNSSEC environment. https://en.wikipedia.org/wiki/Captive_portal | 20:02 |
rwp | Because those work specifically by breaking security and becoming a MITM attacker redirecting queries. | 20:03 |
Wonka | they would not need to, if they used appropriately new stuff - there's WPA IEs telling where to go first after connecting to a Wifi | 20:03 |
rwp | On occasion (Starbucks I am looking at you) I have had to stop unbound, set /etc/resolv.conf to any nameserver, then retry the web browser authorization in order to get access. | 20:03 |
rwp | Also note that newer DoH DNS over HTTP also might need to be temporarily unchecked in the browser in order to allow the MITM attack too. | 20:04 |
Wonka | even more reason to "just" use that WPA IE... | 20:05 |
fsmithred | I haven't noticed any problems with immutable resolv.conf except when I forgot and tried to edit it. | 21:19 |
rwp | Immutable /etc/resolv.conf is fine. I have done it too. But if we had infinite time then fixing things not to need immutable is of course better. | 21:22 |
rwp | Because immutable is a workaround for a bug that exists elsewhere. But I admit I have done it too. No infinite time here either. | 21:23 |
dan9er[m] | tysm rwp!! you guys rock | 21:46 |
dan9er[m] | way better than void linux IRC | 21:46 |
* dan9er[m] shudders | 21:47 | |
dan9er[m] | And also gnarface, drizzt, fsmithred, & onefang were big help too, ty all | 21:52 |
rwp | Speaking for the entire community of helpful people here, You are very welcome dan9er[m]! It's a team effort. Happy to help! :-) | 22:19 |
Soltis | Why the hell is the "Content-Length header was wrong, fixed" message still being emitted in this year of our lord 2022? | 22:48 |
Soltis | God damn it, wrong channel. | 23:03 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!