On Sun, 2019-02-03 at 17:28 +0800, Ed Greshko wrote:
> On 2/3/19 5:15 PM, Patrick O'Callaghan wrote:
> > I may ask them about the current issue but am not very hopeful of a
> > solution. In any case I can work around it.
>
> In reading their web site, it seems the underlying technology is OpenVPN.
On Sat, 2019-02-02 at 14:43 -0800, Mike Wright wrote:
> On 2/2/19 4:22 AM, Patrick O'Callaghan wrote:
> > Last ditch left-field idea: I have a (commercial) VPN service which is
> > not normally turned on but does have a systemd daemon running. I turned
> > it off and everything started working.
> >
On 2/3/19 5:15 PM, Patrick O'Callaghan wrote:
> I may ask them about the current issue but am not very hopeful of a
> solution. In any case I can work around it.
In reading their web site, it seems the underlying technology is OpenVPN. So,
it isn't
clear to me why they would need specialized pro
On Sun, 2019-02-03 at 07:22 +0800, Ed Greshko wrote:
> On 2/3/19 1:55 AM, Patrick O'Callaghan wrote:
> > On Sat, 2019-02-02 at 09:02 -0500, Sam Varshavchik wrote:
> > > Ed Greshko writes:
> > >
> > > > Well, it would be good to
> > > >
> > > > Stop firewalld, dump the IPTables, start the VPN
On 2/3/19 1:55 AM, Patrick O'Callaghan wrote:
> On Sat, 2019-02-02 at 09:02 -0500, Sam Varshavchik wrote:
>> Ed Greshko writes:
>>
>>> Well, it would be good to
>>>
>>> Stop firewalld, dump the IPTables, start the VPN daemon, wait a bit, and
>>> dump the IPTables
>>> again.
>>>
>>> Also, it w
On 2/2/19 4:22 AM, Patrick O'Callaghan wrote:
Last ditch left-field idea: I have a (commercial) VPN service which is
not normally turned on but does have a systemd daemon running. I turned
it off and everything started working.
I'll bet the vpn is messing with your routes.
___
On Sat, 2019-02-02 at 21:50 +0800, Ed Greshko wrote:
> On 2/2/19 8:22 PM, Patrick O'Callaghan wrote:
> > Last ditch left-field idea: I have a (commercial) VPN service which is
> > not normally turned on but does have a systemd daemon running. I turned
> > it off and everything started working.
> >
On Sat, 2019-02-02 at 10:02 -0500, Tom Horsley wrote:
> On Sat, 2 Feb 2019 21:50:55 +0800
> Ed Greshko wrote:
>
> > If you'd made no changes why then did the
> > problem arise?
>
> There are some things man was not meant to know :-).
It's a firewall Jim, but not as we know it ...
poc
__
On Sat, 2019-02-02 at 09:02 -0500, Sam Varshavchik wrote:
> Ed Greshko writes:
>
> > Well, it would be good to
> >
> > Stop firewalld, dump the IPTables, start the VPN daemon, wait a bit, and
> > dump the IPTables
> > again.
> >
> > Also, it would be helpful to actually name the commercial
On Sat, 2 Feb 2019 21:50:55 +0800
Ed Greshko wrote:
> If you'd made no changes why then did the
> problem arise?
There are some things man was not meant to know :-).
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to
Ed Greshko writes:
Well, it would be good to
Stop firewalld, dump the IPTables, start the VPN daemon, wait a bit, and
dump the IPTables
again.
Also, it would be helpful to actually name the commercial VPN which may warn
others about
the pitfall.
Pretty sure it's Cisco Anyconnect.
On 2/2/19 8:22 PM, Patrick O'Callaghan wrote:
> Last ditch left-field idea: I have a (commercial) VPN service which is
> not normally turned on but does have a systemd daemon running. I turned
> it off and everything started working.
>
> I am now looking at 3 Fedora guests and a Windows guest all c
On Sat, 2019-02-02 at 12:01 +, Patrick O'Callaghan wrote:
> On Sat, 2019-02-02 at 10:55 +0800, Ed Greshko wrote:
> > On 2/2/19 6:13 AM, Patrick O'Callaghan wrote:
> > > On Fri, 2019-02-01 at 17:55 +, Patrick O'Callaghan wrote:
> > > > They both show *the same MAC address*: 52:54:00:8b:88:60
On Sat, 2019-02-02 at 10:55 +0800, Ed Greshko wrote:
> On 2/2/19 6:13 AM, Patrick O'Callaghan wrote:
> > On Fri, 2019-02-01 at 17:55 +, Patrick O'Callaghan wrote:
> > > They both show *the same MAC address*: 52:54:00:8b:88:60, which looks
> > > at least suspicious.
> > Correction: the address b
On 2/2/19 6:13 AM, Patrick O'Callaghan wrote:
> On Fri, 2019-02-01 at 17:55 +, Patrick O'Callaghan wrote:
>> They both show *the same MAC address*: 52:54:00:8b:88:60, which looks
>> at least suspicious.
> Correction: the address being shown (while arp is still working) is
> that of the gateway,
On Fri, 2019-02-01 at 17:55 +, Patrick O'Callaghan wrote:
> They both show *the same MAC address*: 52:54:00:8b:88:60, which looks
> at least suspicious.
Correction: the address being shown (while arp is still working) is
that of the gateway, so naturally it's the same in both guests.
poc
On 2/2/19 1:55 AM, Patrick O'Callaghan wrote:
> They both show *the same MAC address*: 52:54:00:8b:88:60, which looks
> at least suspicious. Then after less than a minute I ran 'arp' on each
> of them again, and they both returned a hardware address of
> '(incomplete)'.
That is rather strange.
If
On Wed, 2019-01-30 at 22:47 +0800, Ed Greshko wrote:
> On 1/30/19 9:31 PM, Patrick O'Callaghan wrote:
> > I hesitate to wimp out and reinstall it,
> > but I'm running out of ideas.
>
> Before doing that I think I would create a couple of new F29 VM's and see if
> the new ones
> exhibit the same i
On 1/30/19 9:31 PM, Patrick O'Callaghan wrote:
> I hesitate to wimp out and reinstall it,
> but I'm running out of ideas.
Before doing that I think I would create a couple of new F29 VM's and see if
the new ones
exhibit the same issue as the old ones.
--
Right: I dislike the default color schem
On Wed, 2019-01-30 at 13:01 +, Patrick O'Callaghan wrote:
> I want to try one more thing: leaving the Fedora guest on
> NAT and changing the Windows guest to macvtap (since I don't need to
> connect into it).
Interesting. I changed the Windows guest to macvtap and didn't touch
the Fedora guest
On Wed, 2019-01-30 at 09:19 +0800, Ed Greshko wrote:
> On 1/30/19 1:37 AM, Patrick O'Callaghan wrote:
> > And we're back ...
> >
> > I worked away using the Windows guest for several hours. Network access
> > kept going, though the system felt slightly sluggish at times. When I
> > looked at the F
On 1/30/19 1:37 AM, Patrick O'Callaghan wrote:
> And we're back ...
>
> I worked away using the Windows guest for several hours. Network access
> kept going, though the system felt slightly sluggish at times. When I
> looked at the Fedora guest (which I hadn't touched in all this time) it
> was off
On Tue, 2019-01-29 at 14:59 +, Patrick O'Callaghan wrote:
> On Tue, 2019-01-29 at 20:18 +0800, Ed Greshko wrote:
> > I didn't have a Win10 guest. So, I installed. And tested with a Fedora
> > Guest. Both are
> > still working just fine after
> >
> > [egreshko@f29g ~]$ uptime
> > 20:16:43
On Tue, 2019-01-29 at 20:18 +0800, Ed Greshko wrote:
> I didn't have a Win10 guest. So, I installed. And tested with a Fedora
> Guest. Both are
> still working just fine after
>
> [egreshko@f29g ~]$ uptime
> 20:16:43 up 33 min, 2 users, load average: 0.07, 0.02, 0.00
>
> How about putting
On 1/29/19 7:02 PM, Patrick O'Callaghan wrote:
> OK, first of all the Fedora guest doesn't have libvirt.service enabled,
> maybe because it was installed with no DE.
>
> Secondly, I did the following:
>
> 1) Verified that the Windows guest was still working.
> 2) Started the Fedora guest.
> 3) Both
On Tue, 2019-01-29 at 10:39 +, Patrick O'Callaghan wrote:
> So, maybe, try disabling libvirt.service on any guests which may have it
> enabled and
> > reboot *everything* to see if your problem persists.
>
> Interesting, though I wouldn't expect a difference between Gnome and
> KDE guests. N
On 1/29/19 6:39 PM, Patrick O'Callaghan wrote:
> Interesting, though I wouldn't expect a difference between Gnome and
> KDE guests. Note that my guest is Fedora Server, with no DE installed.
The "difference" is if you install Fedora KDE spin from the Live Media it
Doesn't Install
any libvirt stuf
On Tue, 2019-01-29 at 06:11 +0800, Ed Greshko wrote:
> On 1/28/19 11:55 PM, Patrick O'Callaghan wrote:
> > On Mon, 2019-01-28 at 21:54 +0800, Ed Greshko wrote:
> >
> > > I'll do more in my AM.
> > Thanks again.
> >
>
> Well, yesterday I was able to replicate the symptoms of the problem you're
>
On 1/28/19 11:55 PM, Patrick O'Callaghan wrote:
> On Mon, 2019-01-28 at 21:54 +0800, Ed Greshko wrote:
>
>> I'll do more in my AM.
> Thanks again.
>
Well, yesterday I was able to replicate the symptoms of the problem you're
having. I
can't say if I actually duplicated it. However, this morning
On Mon, 2019-01-28 at 22:20 +0800, Ed Greshko wrote:
> On 1/26/19 6:24 AM, Patrick O'Callaghan wrote:
> > $ systemctl status firewalld
> > ● firewalld.service - firewalld - dynamic firewall daemon
> >Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled;
> > vendor preset: enabled
On Mon, 2019-01-28 at 12:36 +0100, Tom H wrote:
> > Surely you must have virbr0? Not sure where virbr0-nic comes from but I
> > assume it's created by libvirt.
>
> virbr0's MAC is copied from the first NIC that's attached to it. To
> ensure that virbr0 has (1) a MAC (if no NIC's attached, it won't
On Mon, 2019-01-28 at 21:54 +0800, Ed Greshko wrote:
> > > Have you tried with the FW stopped?
> > Well I stopped firewalld, though I don't think that actually stops the
> > FW itself, i.e. iptables in the kernel.
> >
> > Makes no difference.
>
> Well, good news and bad news. The good news is th
On 1/26/19 6:24 AM, Patrick O'Callaghan wrote:
> $ systemctl status firewalld
> ● firewalld.service - firewalld - dynamic firewall daemon
>Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor
> preset: enabled)
>Active: active (running) since Fri 2019-01-25 21:37:32 G
On 1/28/19 9:24 PM, Patrick O'Callaghan wrote:
> On Mon, 2019-01-28 at 19:52 +0800, Ed Greshko wrote:
>> Actually, vnet0, wasn't even there initially until I manually added it to
>> "public".
>> Originally the line read
>>
>> interfaces: enp2s0 wlp4s0
> What zone was it in, as a matter of interes
On Mon, 2019-01-28 at 19:52 +0800, Ed Greshko wrote:
> Actually, vnet0, wasn't even there initially until I manually added it to
> "public".
> Originally the line read
>
> interfaces: enp2s0 wlp4s0
What zone was it in, as a matter of interest?
> I've reverted to this condition.
>
> Have you t
On 1/28/19 6:06 PM, Patrick O'Callaghan wrote:
> On Mon, 2019-01-28 at 08:20 +0800, Ed Greshko wrote:
[egreshko@meimei .ssh]$ sudo firewall-cmd --info-zone=public
public (active)
target: default
icmp-block-inversion: no
interfaces: enp2s0 vnet0 wlp4s0
sourc
On Mon, Jan 28, 2019 at 11:07 AM Patrick O'Callaghan
wrote:
> On Mon, 2019-01-28 at 08:20 +0800, Ed Greshko wrote:
[egreshko@meimei .ssh]$ sudo firewall-cmd --info-zone=public
public (active)
target: default
icmp-block-inversion: no
interfaces: enp2s0 vnet0 wlp4s0
sou
On Mon, 2019-01-28 at 08:20 +0800, Ed Greshko wrote:
> > > [egreshko@meimei .ssh]$ sudo firewall-cmd --info-zone=public
> > > public (active)
> > >target: default
> > >icmp-block-inversion: no
> > >interfaces: enp2s0 vnet0 wlp4s0
> > >sources:
> > >services: dhcpv6-client dns kd
On Mon, 2019-01-28 at 08:32 +0800, Ed Greshko wrote:
> On 1/28/19 7:12 AM, Patrick O'Callaghan wrote:
> > On Mon, 2019-01-28 at 06:18 +0800, Ed Greshko wrote:
> > > If you use wireshark to monitor just vnet0 and do an ssh to the guest do
> > > you see an ARP
> > > request/response happen first? I
On Mon, 2019-01-28 at 08:28 +0800, Ed Greshko wrote:
> On 1/28/19 7:12 AM, Patrick O'Callaghan wrote:
> > Even without trying the ssh there is a constant traffic of ARP requests
> > with no replies:
>
> On the host, do you get no responses when you do
>
> arping -I virbr0 192.168.122.167 ?
>
On 1/28/19 7:12 AM, Patrick O'Callaghan wrote:
> On Mon, 2019-01-28 at 06:18 +0800, Ed Greshko wrote:
>> If you use wireshark to monitor just vnet0 and do an ssh to the guest do you
>> see an ARP
>> request/response happen first? Is it correct?
>>
>> [...]
> Even without trying the ssh there is a
On 1/28/19 7:12 AM, Patrick O'Callaghan wrote:
> Even without trying the ssh there is a constant traffic of ARP requests
> with no replies:
On the host, do you get no responses when you do
arping -I virbr0 192.168.122.167 ?
[egreshko@meimei vnet0]$ arping -I virbr0 192.168.122.86
ARPING 192.
On 1/28/19 7:12 AM, Patrick O'Callaghan wrote:
> Even without trying the ssh there is a constant traffic of ARP requests
> with no replies:
On the host, do you get no responses when you do
arping -I virbr0 192.168.122.167 ?
[egreshko@meimei vnet0]$ arping -I virbr0 192.168.122.86
ARPING 192.
On 1/28/19 7:12 AM, Patrick O'Callaghan wrote:
> On Mon, 2019-01-28 at 06:18 +0800, Ed Greshko wrote:
>> If you use wireshark to monitor just vnet0 and do an ssh to the guest do you
>> see an ARP
>> request/response happen first? Is it correct?
>>
>> [...]
> Even without trying the ssh there is a
On Mon, 2019-01-28 at 06:18 +0800, Ed Greshko wrote:
> If you use wireshark to monitor just vnet0 and do an ssh to the guest do you
> see an ARP
> request/response happen first? Is it correct?
>
> [...]
Even without trying the ssh there is a constant traffic of ARP requests
with no replies:
52
On 1/27/19 10:45 PM, Patrick O'Callaghan wrote:
> Thanks for your patience in looking at this Ed. Don't feel pressured to
> keep responding
I only feel pressure to respond to our cats. Oh, and my wife. Besides, who
doesn't love
a mystery?
When I was talking about the MAC addresses I was specul
On Sun, 2019-01-27 at 21:50 +0800, Ed Greshko wrote:
> On 1/27/19 7:48 AM, Patrick O'Callaghan wrote:
> > Same here. To eliminate some variables, I turned off my dnsmasq
> > service, disabled it and rebooted. The problem is still there: for a
> > few moments the guests are network-reachable, then t
On 1/27/19 7:48 AM, Patrick O'Callaghan wrote:
> Same here. To eliminate some variables, I turned off my dnsmasq
> service, disabled it and rebooted. The problem is still there: for a
> few moments the guests are network-reachable, then they aren't. They
> may come back, they may not. Or one does a
On Sat, 2019-01-26 at 20:26 +0800, Ed Greshko wrote:
> On 1/26/19 7:55 PM, Patrick O'Callaghan wrote:
> > The plot thickens. First of all, my snippet from wireshark was of
> > course wrong as I was monitoring virbr0 instead of vnet0. Silly me.
> >
> > Secondly, after a reboot to make sure everythi
On 1/26/19 7:55 PM, Patrick O'Callaghan wrote:
> The plot thickens. First of all, my snippet from wireshark was of
> course wrong as I was monitoring virbr0 instead of vnet0. Silly me.
>
> Secondly, after a reboot to make sure everything was in default state,
> I fired up the Fedora guest alone, an
On Sat, 2019-01-26 at 07:18 +0800, Ed Greshko wrote:
> > I tried reloading firewalld and got the same result. I fired up the
> > firewall applet and suddenly the guests had network access, even though
> > I didn't change anything. I quit the applet and boom, the guests lost
> > network access again
On 1/26/19 6:24 AM, Patrick O'Callaghan wrote:
> I'm 99% sure it has something to do with the firewall. Thing is, I
> haven't touched the firewall rules. Nevertheless I see this:
>
> $ systemctl status firewalld
> ● firewalld.service - firewalld - dynamic firewall daemon
>Loaded: loaded (/usr/l
On Fri, 2019-01-25 at 17:07 +, Patrick O'Callaghan wrote:
> On Fri, 2019-01-25 at 15:51 +, Patrick O'Callaghan wrote:
> > Pings in both directions fail, in case that wasn't clear. BTW the
> > Windows guest also fails in the same way.
> >
> > I'm at a loss.
> >
> Just to add that I attempt
On Fri, 2019-01-25 at 15:51 +, Patrick O'Callaghan wrote:
> Pings in both directions fail, in case that wasn't clear. BTW the
> Windows guest also fails in the same way.
>
> I'm at a loss.
>
Just to add that I attempted to set up a fresh Fedora server guest
(from a netinst.iso), using the def
On Fri, 2019-01-25 at 12:40 +, Patrick O'Callaghan wrote:
> On Fri, 2019-01-25 at 20:13 +0800, Ed Greshko wrote:
> > On 1/25/19 8:06 PM, Patrick O'Callaghan wrote:
> > > On Thu, 2019-01-24 at 22:40 +0800, Ed Greshko wrote:
> > > > On 1/24/19 8:08 PM, Patrick O'Callaghan wrote:
> > > > > I updat
On Fri, 2019-01-25 at 20:13 +0800, Ed Greshko wrote:
> On 1/25/19 8:06 PM, Patrick O'Callaghan wrote:
> > On Thu, 2019-01-24 at 22:40 +0800, Ed Greshko wrote:
> > > On 1/24/19 8:08 PM, Patrick O'Callaghan wrote:
> > > > I updated my system this morning. Updated packages included a new
> > > > kerne
On 1/25/19 8:06 PM, Patrick O'Callaghan wrote:
> On Thu, 2019-01-24 at 22:40 +0800, Ed Greshko wrote:
>> On 1/24/19 8:08 PM, Patrick O'Callaghan wrote:
>>> I updated my system this morning. Updated packages included a new
>>> kernel and some SElinux stuff among other things (the complete list is
>>
On Thu, 2019-01-24 at 22:40 +0800, Ed Greshko wrote:
> On 1/24/19 8:08 PM, Patrick O'Callaghan wrote:
> > I updated my system this morning. Updated packages included a new
> > kernel and some SElinux stuff among other things (the complete list is
> > attached). I now find that neither of my QEMU/KV
On Thu, 2019-01-24 at 14:01 +0100, Kai Bojens wrote:
> On 24/01/2019 –– 12:08:03PM +, Patrick O'Callaghan wrote:
>
> > Before trying to downgrade the entire update, is there anything else I
> > can do?
>
> Well, what do the logfiles tell you? Does journalctl have any information
> about
> t
On Thu, 2019-01-24 at 21:41 +, YOUNG, MICHAEL A. wrote:
> On 24/01/2019 –– 12:08:03PM +, Patrick O'Callaghan wrote:
> > Before trying to downgrade the entire update, is there anything else I
> > can do?
>
> Can you boot from another kernel? I have had problems with network and GUI
> with
On 24/01/2019 –– 12:08:03PM +, Patrick O'Callaghan wrote:
> Before trying to downgrade the entire update, is there anything else I
> can do?
Can you boot from another kernel? I have had problems with network and GUI
with kernel-4.20.3-200.fc29.x86_64 on a xen Dom0, so it might be worth
tryin
On 1/24/19 8:08 PM, Patrick O'Callaghan wrote:
> I updated my system this morning. Updated packages included a new
> kernel and some SElinux stuff among other things (the complete list is
> attached). I now find that neither of my QEMU/KVM guests (one Fedora,
> one Windows 10) have Internet access,
On 24/01/2019 –– 12:08:03PM +, Patrick O'Callaghan wrote:
> Before trying to downgrade the entire update, is there anything else I
> can do?
Well, what do the logfiles tell you? Does journalctl have any information about
this? Are there any error messages?
___
I updated my system this morning. Updated packages included a new
kernel and some SElinux stuff among other things (the complete list is
attached). I now find that neither of my QEMU/KVM guests (one Fedora,
one Windows 10) have Internet access, though they do have access to my
host. They were both
64 matches
Mail list logo
