[18:25] <tgp1994> Hi everyone, hope I can ask a potentially dumb question here regarding apache. I recently had to restore my virtual machine (Ubuntu server 20.04.2) from a backup due to a corruption issue, and so far everything seems nominal. I can access a webservice from my phone, but if I try to access it from my
[18:25] <tgp1994> out or report that the connection was reset. I can ping the virutal machine, and I can see that port 443 is open. But for some reason my browsers cannot get a response. The access.log indicated my phone is accessing it, but there's no mention of my desktop. Does anyone have any idea what's going on?
[18:25] <tgp1994> desktop, my browsers (Edge and Firefox) will time
[18:29] <tgp1994> Update: running wireshark, I see the initial GET then a bunch of TCP retransmission packets and "spurious retransmission" packets along with a few TCP Dup ACK packets. Odd...
[18:30] <tgp1994> Finally rounded out with a reset.
[18:38] <tgp1994_> Huh, here's interesting. I disabled IPv6 on my machine, then I was able to connect. When I re-enabled IPv6, I'm still able to browse just fine. Something seems off, but at least it's working now.
[18:39] <tomreyn> part of your initial message was apparently lost in the line break
[18:41] <tgp1994_> tomreyn: Ah, shoot. When I switched off IPv6 my IRC client forgot everything so I can't repaste, but TL;DR is my desktop couldn't connect to apache2 and was timing out/getting connection reset. when I disabled IPv6 it started working, and now when I enabled it, it still works... no idea what's going
[18:41] <tgp1994_> on.
[18:43] <tomreyn> chances are the web server or its host isn't configured to listen on ipv6 then
[18:44] <tomreyn> (or doesn't have an ipv6 stack in the first place)
[18:44] <tgp1994_> I'm not sure about that, because my phone was able to connect fine and even my desktop is working fine now over IPv6, too. I want to chalk it up to Windows 10 just being windows....
[19:07] <tomreyn> right, then my wild guess was incorrect
[20:08] <tgp1994_> Sorry, I think I may need to ask another dumb question: How do control what TTY ubuntu server boots to? Currently when booting, it will stay in the dmesg TTY (7) but I'd prefer it if it'd switch to TTY1 at the first opportunity.
[21:00] <xue> hi
[21:00] <xue> i had really old usb wifi dongle and it is not well supported by netplan 
[21:01] <xue> can someone tell me, which of the serices i should disable to run connman?
[21:01] <xue> its clean installation, im just not daily systemd user so i have troubles to look through current config
[21:15] <shibboleth> get rid of netplan?
[21:15] <shibboleth> https://askubuntu.com/questions/1031709/ubuntu-18-04-switch-back-to-etc-network-interfaces
[21:16] <xue> connman has its own dhcp implementation so i need to turn that off
[21:17] <xue> basically everything that is used to manage intenet connection
[21:45] <xue> gsker: hi
[21:45] <xue> ive been waiting here
[21:46] <xue> │23:00:05        xue | hi 
[21:52] <patdk-lap> very odd
[21:53] <patdk-lap> I have moved everything over to netplan, mainly cause it's configuration is not as insanely large and confusing as network interfaces, just a few getyas to resolve
[21:53] <patdk-lap> for awhile there the mtu issue and also interface renaming
[21:59] <oerheks> patdk-lap, we found out in #ubuntu that 'not well supported by netplan' is not true, just a choice
[22:00] <xue> gsker: please defend me
[22:03] <xue> patdk-lap: you wanna hear whole story?
[22:04] <patdk-lap> not really
[22:04] <xue> tl;dr dongle is old
[22:05] <patdk-lap> old makes no sense, old generally means well supported, cause it's had time to get support
[22:05] <patdk-lap> and wifi stack is very known, so that should be only a driver issue
[22:05] <patdk-lap> but then you went on about a dhcp issue, but then netplan doesn't deal with dhcp so
[22:06] <patdk-lap> for me, pure netplan issue, setting mtu was completely broken, unless mac address was specifified, though that appears to have been fixed at one point ,cause it's no longer an issue for me
[22:07] <patdk-lap> renaming, still an issue, if another interface is using that name, it just completely fails, and doesn't move the other one out of the way, even if you try to rename both
[22:08] <patdk-lap> renaming is a requirement though, as corosync/pacemaker needs consistant names across hosts