* Re: [PATCH] NFC: st95hf: fix spelling mistake "receieve" -> "receive"
From: David Miller @ 2019-09-11 14:07 UTC (permalink / raw)
To: colin.king; +Cc: gregkh, netdev, kernel-janitors, linux-kernel
In-Reply-To: <20190911103848.17966-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Wed, 11 Sep 2019 11:38:48 +0100
> From: Colin Ian King <colin.king@canonical.com>
>
> There is a spelling mistake in a dev_err message. Fix it.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net] net/rds: An rds_sock is added too early to the hash table
From: David Miller @ 2019-09-11 14:06 UTC (permalink / raw)
To: ka-cheong.poon; +Cc: netdev, santosh.shilimkar, rds-devel
In-Reply-To: <1568195885-6285-1-git-send-email-ka-cheong.poon@oracle.com>
From: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Date: Wed, 11 Sep 2019 02:58:05 -0700
> In rds_bind(), an rds_sock is added to the RDS bind hash table before
> rs_transport is set. This means that the socket can be found by the
> receive code path when rs_transport is NULL. And the receive code
> path de-references rs_transport for congestion update check. This can
> cause a panic. An rds_sock should not be added to the bind hash table
> before all the needed fields are set.
>
> Reported-by: syzbot+4b4f8163c2e246df3c4c@syzkaller.appspotmail.com
> Signed-off-by: Ka-Cheong Poon <ka-cheong.poon@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH] mac80211: Do not send Layer 2 Update frame before authorization
From: David Miller @ 2019-09-11 13:59 UTC (permalink / raw)
To: johannes; +Cc: jouni, linux-wireless, netdev
In-Reply-To: <d0de07f0918863c8bc9bebccd8c6a7402a2ad173.camel@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 11 Sep 2019 15:06:03 +0200
> On Wed, 2019-09-11 at 16:03 +0300, Jouni Malinen wrote:
>> The Layer 2 Update frame is used to update bridges when a station roams
>> to another AP even if that STA does not transmit any frames after the
>> reassociation. This behavior was described in IEEE Std 802.11F-2003 as
>> something that would happen based on MLME-ASSOCIATE.indication, i.e.,
>> before completing 4-way handshake. However, this IEEE trial-use
>> recommended practice document was published before RSN (IEEE Std
>> 802.11i-2004) and as such, did not consider RSN use cases. Furthermore,
>> IEEE Std 802.11F-2003 was withdrawn in 2006 and as such, has not been
>> maintained amd should not be used anymore.
>>
>> Sending out the Layer 2 Update frame immediately after association is
>> fine for open networks (and also when using SAE, FT protocol, or FILS
>> authentication when the station is actually authenticated by the time
>> association completes). However, it is not appropriate for cases where
>> RSN is used with PSK or EAP authentication since the station is actually
>> fully authenticated only once the 4-way handshake completes after
>> authentication and attackers might be able to use the unauthenticated
>> triggering of Layer 2 Update frame transmission to disrupt bridge
>> behavior.
>>
>> Fix this by postponing transmission of the Layer 2 Update frame from
>> station entry addition to the point when the station entry is marked
>> authorized. Similarly, send out the VLAN binding update only if the STA
>> entry has already been authorized.
>
> Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
>
> Dave, if you were still planning to send a pull request to Linus before
> he closes the tree on Sunday this would be good to include (and we
> should also backport it to stable later).
>
> If not, I can pick it up afterwards, let me know.
Ok I applied this directly, thanks.
^ permalink raw reply
* Re: pull-request: mac80211-next 2019-09-11
From: David Miller @ 2019-09-11 13:57 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190911131326.24032-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 11 Sep 2019 15:13:25 +0200
> As detailed below, here are some more changes for -next, almost
> certainly the final round since the merge window is around the
> corner now.
>
> Please pull and let me know if there's any problem.
Pulled, thanks Johannes.
^ permalink raw reply
* Re: [PATCH v3 0/5] Introduce variable length mdev alias
From: Alex Williamson @ 2019-09-11 13:56 UTC (permalink / raw)
To: Parav Pandit
Cc: Jiri Pirko, kwankhede@nvidia.com, cohuck@redhat.com,
davem@davemloft.net, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org
In-Reply-To: <AM0PR05MB4866F76F807409ED887537D7D1B70@AM0PR05MB4866.eurprd05.prod.outlook.com>
On Mon, 9 Sep 2019 20:42:32 +0000
Parav Pandit <parav@mellanox.com> wrote:
> Hi Alex,
>
> > -----Original Message-----
> > From: Parav Pandit <parav@mellanox.com>
> > Sent: Sunday, September 1, 2019 11:25 PM
> > To: alex.williamson@redhat.com; Jiri Pirko <jiri@mellanox.com>;
> > kwankhede@nvidia.com; cohuck@redhat.com; davem@davemloft.net
> > Cc: kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
> > netdev@vger.kernel.org; Parav Pandit <parav@mellanox.com>
> > Subject: [PATCH v3 0/5] Introduce variable length mdev alias
> >
> > To have consistent naming for the netdevice of a mdev and to have consistent
> > naming of the devlink port [1] of a mdev, which is formed using
> > phys_port_name of the devlink port, current UUID is not usable because UUID
> > is too long.
> >
> > UUID in string format is 36-characters long and in binary 128-bit.
> > Both formats are not able to fit within 15 characters limit of netdev name.
> >
> > It is desired to have mdev device naming consistent using UUID.
> > So that widely used user space framework such as ovs [2] can make use of
> > mdev representor in similar way as PCIe SR-IOV VF and PF representors.
> >
> > Hence,
> > (a) mdev alias is created which is derived using sha1 from the mdev name.
> > (b) Vendor driver describes how long an alias should be for the child mdev
> > created for a given parent.
> > (c) Mdev aliases are unique at system level.
> > (d) alias is created optionally whenever parent requested.
> > This ensures that non networking mdev parents can function without alias
> > creation overhead.
> >
> > This design is discussed at [3].
> >
> > An example systemd/udev extension will have,
> >
> > 1. netdev name created using mdev alias available in sysfs.
> >
> > mdev UUID=83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
> > mdev 12 character alias=cd5b146a80a5
> >
> > netdev name of this mdev = enmcd5b146a80a5 Here en = Ethernet link m =
> > mediated device
> >
> > 2. devlink port phys_port_name created using mdev alias.
> > devlink phys_port_name=pcd5b146a80a5
> >
> > This patchset enables mdev core to maintain unique alias for a mdev.
> >
> > Patch-1 Introduces mdev alias using sha1.
> > Patch-2 Ensures that mdev alias is unique in a system.
> > Patch-3 Exposes mdev alias in a sysfs hirerchy, update Documentation
> > Patch-4 Introduces mdev_alias() API.
> > Patch-5 Extends mtty driver to optionally provide alias generation.
> > This also enables to test UUID based sha1 collision and trigger error handling
> > for duplicate sha1 results.
> >
> > [1] http://man7.org/linux/man-pages/man8/devlink-port.8.html
> > [2] https://docs.openstack.org/os-vif/latest/user/plugins/ovs.html
> > [3] https://patchwork.kernel.org/cover/11084231/
> >
> > ---
> > Changelog:
> > v2->v3:
> > - Addressed comment from Yunsheng Lin
> > - Changed strcmp() ==0 to !strcmp()
> > - Addressed comment from Cornelia Hunk
> > - Merged sysfs Documentation patch with syfs patch
> > - Added more description for alias return value
>
> Did you get a chance review this updated series?
> I addressed Cornelia's and yours comment.
> I do not think allocating alias memory twice, once for comparison and
> once for storing is good idea or moving alias generation logic inside
> the mdev_list_lock(). So I didn't address that suggestion of
> Cornelia.
Sorry, I'm at LPC this week. I agree, I don't think the double
allocation is necessary, I thought the comment was sufficient to
clarify null'ing the variable. It's awkward, but seems correct.
I'm not sure what we do with this patch series though, has the real
consumer of this even been proposed? It feels optimistic to include at
this point. We've used the sample driver as a placeholder in the past
for mdev_uuid(), but we arrived at that via a conversion rather than
explicitly adding the API. Please let me know where the consumer
patches stand, perhaps it would make more sense for them to go in
together rather than risk adding an unused API. Thanks,
Alex
> > v1->v2:
> > - Corrected a typo from 'and' to 'an'
> > - Addressed comments from Alex Williamson
> > - Kept mdev_device naturally aligned
> > - Added error checking for crypt_*() calls
> > - Moved alias NULL check at beginning
> > - Added mdev_alias() API
> > - Updated mtty driver to show example mdev_alias() usage
> > - Changed return type of generate_alias() from int to char*
> > v0->v1:
> > - Addressed comments from Alex Williamson, Cornelia Hunk and Mark
> > Bloch
> > - Moved alias length check outside of the parent lock
> > - Moved alias and digest allocation from kvzalloc to kzalloc
> > - &alias[0] changed to alias
> > - alias_length check is nested under get_alias_length callback
> > check
> > - Changed comments to start with an empty line
> > - Added comment where alias memory ownership is handed over to mdev
> > device
> > - Fixed cleaunup of hash if mdev_bus_register() fails
> > - Updated documentation for new sysfs alias file
> > - Improved commit logs to make description more clear
> > - Fixed inclusiong of alias for NULL check
> > - Added ratelimited debug print for sha1 hash collision error
> >
> > Parav Pandit (5):
> > mdev: Introduce sha1 based mdev alias
> > mdev: Make mdev alias unique among all mdevs
> > mdev: Expose mdev alias in sysfs tree
> > mdev: Introduce an API mdev_alias
> > mtty: Optionally support mtty alias
> >
> > .../driver-api/vfio-mediated-device.rst | 9 ++
> > drivers/vfio/mdev/mdev_core.c | 142
> > +++++++++++++++++- drivers/vfio/mdev/mdev_private.h
> > | 5 +- drivers/vfio/mdev/mdev_sysfs.c | 26 +++-
> > include/linux/mdev.h | 5 +
> > samples/vfio-mdev/mtty.c | 13 ++
> > 6 files changed, 190 insertions(+), 10 deletions(-)
> >
> > --
> > 2.19.2
>
^ permalink raw reply
* Re: [PATCH v2] vhost: block speculation of translated descriptors
From: Michael S. Tsirkin @ 2019-09-11 13:52 UTC (permalink / raw)
To: linux-kernel; +Cc: Jason Wang, kvm, virtualization, netdev, security
In-Reply-To: <20190911120908.28410-1-mst@redhat.com>
On Wed, Sep 11, 2019 at 08:10:00AM -0400, Michael S. Tsirkin wrote:
> iovec addresses coming from vhost are assumed to be
> pre-validated, but in fact can be speculated to a value
> out of range.
>
> Userspace address are later validated with array_index_nospec so we can
> be sure kernel info does not leak through these addresses, but vhost
> must also not leak userspace info outside the allowed memory table to
> guests.
>
> Following the defence in depth principle, make sure
> the address is not validated out of node range.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Acked-by: Jason Wang <jasowang@redhat.com>
> Tested-by: Jason Wang <jasowang@redhat.com>
> ---
Cc: security@kernel.org
Pls advise on whether you'd like me to merge this directly,
Cc stable, or handle it in some other way.
> changes from v1: fix build on 32 bit
>
> drivers/vhost/vhost.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 5dc174ac8cac..34ea219936e3 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -2071,8 +2071,10 @@ static int translate_desc(struct vhost_virtqueue *vq, u64 addr, u32 len,
> _iov = iov + ret;
> size = node->size - addr + node->start;
> _iov->iov_len = min((u64)len - s, size);
> - _iov->iov_base = (void __user *)(unsigned long)
> - (node->userspace_addr + addr - node->start);
> + _iov->iov_base = (void __user *)
> + ((unsigned long)node->userspace_addr +
> + array_index_nospec((unsigned long)(addr - node->start),
> + node->size));
> s += size;
> addr += size;
> ++ret;
> --
> MST
^ permalink raw reply
* Re: [PATCH v2] vhost: block speculation of translated descriptors
From: Michael S. Tsirkin @ 2019-09-11 13:51 UTC (permalink / raw)
To: Michal Hocko; +Cc: linux-kernel, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <20190911131235.GZ4023@dhcp22.suse.cz>
On Wed, Sep 11, 2019 at 03:12:35PM +0200, Michal Hocko wrote:
> On Wed 11-09-19 09:03:10, Michael S. Tsirkin wrote:
> > On Wed, Sep 11, 2019 at 02:33:16PM +0200, Michal Hocko wrote:
> > > On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> > > > On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> > > > > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > > > > > iovec addresses coming from vhost are assumed to be
> > > > > > pre-validated, but in fact can be speculated to a value
> > > > > > out of range.
> > > > > >
> > > > > > Userspace address are later validated with array_index_nospec so we can
> > > > > > be sure kernel info does not leak through these addresses, but vhost
> > > > > > must also not leak userspace info outside the allowed memory table to
> > > > > > guests.
> > > > > >
> > > > > > Following the defence in depth principle, make sure
> > > > > > the address is not validated out of node range.
> > > > > >
> > > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > > > Acked-by: Jason Wang <jasowang@redhat.com>
> > > > > > Tested-by: Jason Wang <jasowang@redhat.com>
> > > > >
> > > > > no need to mark fo stable? Other spectre fixes tend to be backported
> > > > > even when the security implications are not really clear. The risk
> > > > > should be low and better to be covered in case.
> > > >
> > > > This is not really a fix - more a defence in depth thing,
> > > > quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd
> > > > x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
> > > > in scope.
> > > >
> > > > That one doesn't seem to be tagged for stable. Was it queued
> > > > there in practice?
> > >
> > > not marked for stable but it went in. At least to 4.4.
> >
> > So I guess the answer is I don't know. If you feel it's
> > justified, then sure, feel free to forward.
>
> Well, that obviously depends on you as a maintainer but the point is
> that spectre gatgets are quite hard to find. There is a smack check
> AFAIK but that generates quite some false possitives and it is PITA to
> crawl through those. If you want an interesting (I am not saying
> vulnerable on purpose) gatget then it would be great to mark it for
> stable so all stable consumers (disclaimer: I am not one of those) and
> add that really great feeling of safety ;)
>
> So take this as my 2c
OK it seems security@kernel.org is the way to handle these things.
I'll try that.
> --
> Michal Hocko
> SUSE Labs
^ permalink raw reply
* Re: WARNING at net/mac80211/sta_info.c:1057 (__sta_info_destroy_part2())
From: Kalle Valo @ 2019-09-11 13:32 UTC (permalink / raw)
To: Johannes Berg
Cc: Linus Torvalds, David S. Miller, linux-wireless, Netdev,
Linux List Kernel Mailing
In-Reply-To: <30679d3f86731475943856196478677e70a349a9.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
>> Sep 11 10:27:13 xps13 kernel: WARNING: CPU: 4 PID: 1246 at
>> net/mac80211/sta_info.c:1057 __sta_info_destroy_part2+0x147/0x150
>> [mac80211]
>>
>> but if you want full logs I can send them in private to you.
>
> No, it's fine, though maybe Kalle does - he was stepping out for a while
> but said he'd look later.
Linus, it would help if you could send me full logs with timestamps.
Also if you can, please grep your logs to see if these wmi timeouts have
happened before.
--
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: WARNING at net/mac80211/sta_info.c:1057 (__sta_info_destroy_part2())
From: Ben Greear @ 2019-09-11 13:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Berg, David S. Miller, Kalle Valo, linux-wireless,
Netdev, Linux List Kernel Mailing
In-Reply-To: <CAHk-=wgAXAw=U_kthB9mG+MBocpawxCzo=6WDrbGgOUr+ac3CA@mail.gmail.com>
On 09/11/2019 06:21 AM, Linus Torvalds wrote:
> On Wed, Sep 11, 2019 at 2:03 PM Ben Greear <greearb@candelatech.com> wrote:
>>
>> Out of curiosity, I'm interested to know what ath10k NIC chipset this is from.
>
> It's a Dell XPS 13 9380, with
>
> 02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac
> Wireless Network Adapter (rev 32)
> Subsystem: Bigfoot Networks, Inc. Killer 1435 Wireless-AC
>
> (numeric PCI ID 168c:003e, subsystem 1a56:143a).
>
> The ath10k driver says
>
> qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:143a
> firmware ver WLAN.RM.4.4.1-00140-QCARMSWPZ-1 api 6 features
> wowlan,ignore-otp,mfp crc32 29eb8ca1
> board_file api 2 bmi_id N/A crc32 4ed3569e
>
> if that tells you anything more.
That means it is something I have never used nor have firmware for, but
the WMI logic should be similar to what I described and have experienced
with other chips.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: WARNING at net/mac80211/sta_info.c:1057 (__sta_info_destroy_part2())
From: Linus Torvalds @ 2019-09-11 13:21 UTC (permalink / raw)
To: Ben Greear
Cc: Johannes Berg, David S. Miller, Kalle Valo, linux-wireless,
Netdev, Linux List Kernel Mailing
In-Reply-To: <2d673d55-eb27-8573-b8ae-a493335723cf@candelatech.com>
On Wed, Sep 11, 2019 at 2:03 PM Ben Greear <greearb@candelatech.com> wrote:
>
> Out of curiosity, I'm interested to know what ath10k NIC chipset this is from.
It's a Dell XPS 13 9380, with
02:00.0 Network controller: Qualcomm Atheros QCA6174 802.11ac
Wireless Network Adapter (rev 32)
Subsystem: Bigfoot Networks, Inc. Killer 1435 Wireless-AC
(numeric PCI ID 168c:003e, subsystem 1a56:143a).
The ath10k driver says
qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 1a56:143a
firmware ver WLAN.RM.4.4.1-00140-QCARMSWPZ-1 api 6 features
wowlan,ignore-otp,mfp crc32 29eb8ca1
board_file api 2 bmi_id N/A crc32 4ed3569e
if that tells you anything more.
Linus
^ permalink raw reply
* pull-request: mac80211-next 2019-09-11
From: Johannes Berg @ 2019-09-11 13:13 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
As detailed below, here are some more changes for -next, almost
certainly the final round since the merge window is around the
corner now.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit c76c992525245ec1c7b6738bf887c42099abab02:
nexthops: remove redundant assignment to variable err (2019-08-22 12:14:05 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2019-09-11
for you to fetch changes up to c1d3ad84eae35414b6b334790048406bd6301b12:
cfg80211: Purge frame registrations on iftype change (2019-09-11 10:45:10 +0200)
----------------------------------------------------------------
We have a number of changes, but things are settling down:
* a fix in the new 6 GHz channel support
* a fix for recent minstrel (rate control) updates
for an infinite loop
* handle interface type changes better wrt. management frame
registrations (for management frames sent to userspace)
* add in-BSS RX time to survey information
* handle HW rfkill properly if !CONFIG_RFKILL
* send deauth on IBSS station expiry, to avoid state mismatches
* handle deferred crypto tailroom updates in mac80211 better
when device restart happens
* fix a spectre-v1 - really a continuation of a previous patch
* advertise NL80211_CMD_UPDATE_FT_IES as supported if so
* add some missing parsing in VHT extended NSS support
* support HE in mac80211_hwsim
* let mac80211 drivers determine the max MTU themselves
along with the usual cleanups etc.
----------------------------------------------------------------
Arend van Spriel (1):
cfg80211: fix boundary value in ieee80211_frequency_to_channel()
Colin Ian King (1):
mac80211: minstrel_ht: fix infinite loop because supported is not being shifted
Denis Kenzior (1):
cfg80211: Purge frame registrations on iftype change
Felix Fietkau (1):
cfg80211: add local BSS receive time to survey information
Johannes Berg (4):
cfg80211: always shut down on HW rfkill
mac80211: list features in WEP/TKIP disable in better order
mac80211: remove unnecessary key condition
mac80211: IBSS: send deauth when expiring inactive STAs
Lior Cohen (1):
mac80211: clear crypto tx tailroom counter upon keys enable
Luca Coelho (1):
mac80211: don't check if key is NULL in ieee80211_key_link()
Masashi Honma (1):
nl80211: Fix possible Spectre-v1 for CQM RSSI thresholds
Matthew Wang (1):
nl80211: add NL80211_CMD_UPDATE_FT_IES to supported commands
Mordechay Goodstein (1):
mac80211: vht: add support VHT EXT NSS BW in parsing VHT
Sven Eckelmann (1):
mac80211_hwsim: Register support for HE meshpoint
Wen Gong (1):
mac80211: allow drivers to set max MTU
zhong jiang (1):
cfg80211: Do not compare with boolean in nl80211_common_reg_change_event
drivers/net/wireless/mac80211_hwsim.c | 283 +++++++++++++++++++++++-----------
include/net/cfg80211.h | 4 +
include/net/mac80211.h | 3 +
include/uapi/linux/nl80211.h | 3 +
net/mac80211/ibss.c | 8 +
net/mac80211/ieee80211_i.h | 3 +-
net/mac80211/iface.c | 2 +-
net/mac80211/key.c | 48 ++----
net/mac80211/key.h | 4 +-
net/mac80211/main.c | 1 +
net/mac80211/mlme.c | 13 +-
net/mac80211/rc80211_minstrel_ht.c | 2 +-
net/mac80211/util.c | 11 +-
net/mac80211/vht.c | 10 +-
net/wireless/core.c | 13 +-
net/wireless/core.h | 2 +-
net/wireless/nl80211.c | 17 +-
net/wireless/util.c | 3 +-
net/wireless/wext-compat.c | 5 +-
19 files changed, 274 insertions(+), 161 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] vhost: block speculation of translated descriptors
From: Michal Hocko @ 2019-09-11 13:12 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <20190911085807-mutt-send-email-mst@kernel.org>
On Wed 11-09-19 09:03:10, Michael S. Tsirkin wrote:
> On Wed, Sep 11, 2019 at 02:33:16PM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> > > On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> > > > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > > > > iovec addresses coming from vhost are assumed to be
> > > > > pre-validated, but in fact can be speculated to a value
> > > > > out of range.
> > > > >
> > > > > Userspace address are later validated with array_index_nospec so we can
> > > > > be sure kernel info does not leak through these addresses, but vhost
> > > > > must also not leak userspace info outside the allowed memory table to
> > > > > guests.
> > > > >
> > > > > Following the defence in depth principle, make sure
> > > > > the address is not validated out of node range.
> > > > >
> > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > > Acked-by: Jason Wang <jasowang@redhat.com>
> > > > > Tested-by: Jason Wang <jasowang@redhat.com>
> > > >
> > > > no need to mark fo stable? Other spectre fixes tend to be backported
> > > > even when the security implications are not really clear. The risk
> > > > should be low and better to be covered in case.
> > >
> > > This is not really a fix - more a defence in depth thing,
> > > quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd
> > > x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
> > > in scope.
> > >
> > > That one doesn't seem to be tagged for stable. Was it queued
> > > there in practice?
> >
> > not marked for stable but it went in. At least to 4.4.
>
> So I guess the answer is I don't know. If you feel it's
> justified, then sure, feel free to forward.
Well, that obviously depends on you as a maintainer but the point is
that spectre gatgets are quite hard to find. There is a smack check
AFAIK but that generates quite some false possitives and it is PITA to
crawl through those. If you want an interesting (I am not saying
vulnerable on purpose) gatget then it would be great to mark it for
stable so all stable consumers (disclaimer: I am not one of those) and
add that really great feeling of safety ;)
So take this as my 2c
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH] mac80211: Do not send Layer 2 Update frame before authorization
From: Johannes Berg @ 2019-09-11 13:06 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, David Miller, netdev
In-Reply-To: <20190911130305.23704-1-jouni@codeaurora.org>
On Wed, 2019-09-11 at 16:03 +0300, Jouni Malinen wrote:
> The Layer 2 Update frame is used to update bridges when a station roams
> to another AP even if that STA does not transmit any frames after the
> reassociation. This behavior was described in IEEE Std 802.11F-2003 as
> something that would happen based on MLME-ASSOCIATE.indication, i.e.,
> before completing 4-way handshake. However, this IEEE trial-use
> recommended practice document was published before RSN (IEEE Std
> 802.11i-2004) and as such, did not consider RSN use cases. Furthermore,
> IEEE Std 802.11F-2003 was withdrawn in 2006 and as such, has not been
> maintained amd should not be used anymore.
>
> Sending out the Layer 2 Update frame immediately after association is
> fine for open networks (and also when using SAE, FT protocol, or FILS
> authentication when the station is actually authenticated by the time
> association completes). However, it is not appropriate for cases where
> RSN is used with PSK or EAP authentication since the station is actually
> fully authenticated only once the 4-way handshake completes after
> authentication and attackers might be able to use the unauthenticated
> triggering of Layer 2 Update frame transmission to disrupt bridge
> behavior.
>
> Fix this by postponing transmission of the Layer 2 Update frame from
> station entry addition to the point when the station entry is marked
> authorized. Similarly, send out the VLAN binding update only if the STA
> entry has already been authorized.
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
Dave, if you were still planning to send a pull request to Linus before
he closes the tree on Sunday this would be good to include (and we
should also backport it to stable later).
If not, I can pick it up afterwards, let me know.
Thanks,
johannes
^ permalink raw reply
* [PATCH iproute2-next] devlink: add 'reset_dev_on_drv_probe' devlink param
From: Simon Horman @ 2019-09-11 13:05 UTC (permalink / raw)
To: David Ahern
Cc: Jiri Pirko, netdev, oss-drivers, Jakub Kicinski,
Dirk van der Merwe, Simon Horman
From: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Add support for the new devlink parameter along with string to uint
conversion.
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Signed-off-by: Simon Horman <simon.horman@netronome.com>
---
Depends on devlink.h changes present in net-next commit
5bbd21df5a07 ("devlink: add 'reset_dev_on_drv_probe' param")
---
devlink/devlink.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/devlink/devlink.c b/devlink/devlink.c
index 2f084c020765..15877a04f5d6 100644
--- a/devlink/devlink.c
+++ b/devlink/devlink.c
@@ -2253,6 +2253,26 @@ static const struct param_val_conv param_val_conv[] = {
.vstr = "flash",
.vuint = DEVLINK_PARAM_FW_LOAD_POLICY_VALUE_FLASH,
},
+ {
+ .name = "reset_dev_on_drv_probe",
+ .vstr = "unknown",
+ .vuint = DEVLINK_PARAM_RESET_DEV_ON_DRV_PROBE_VALUE_UNKNOWN,
+ },
+ {
+ .name = "reset_dev_on_drv_probe",
+ .vstr = "always",
+ .vuint = DEVLINK_PARAM_RESET_DEV_ON_DRV_PROBE_VALUE_ALWAYS,
+ },
+ {
+ .name = "reset_dev_on_drv_probe",
+ .vstr = "never",
+ .vuint = DEVLINK_PARAM_RESET_DEV_ON_DRV_PROBE_VALUE_NEVER,
+ },
+ {
+ .name = "reset_dev_on_drv_probe",
+ .vstr = "disk",
+ .vuint = DEVLINK_PARAM_RESET_DEV_ON_DRV_PROBE_VALUE_DISK,
+ },
};
#define PARAM_VAL_CONV_LEN ARRAY_SIZE(param_val_conv)
--
2.11.0
^ permalink raw reply related
* Re: WARNING at net/mac80211/sta_info.c:1057 (__sta_info_destroy_part2())
From: Ben Greear @ 2019-09-11 13:03 UTC (permalink / raw)
To: Johannes Berg, Linus Torvalds
Cc: David S. Miller, Kalle Valo, linux-wireless, Netdev,
Linux List Kernel Mailing
In-Reply-To: <30679d3f86731475943856196478677e70a349a9.camel@sipsolutions.net>
On 09/11/2019 05:04 AM, Johannes Berg wrote:
> On Wed, 2019-09-11 at 12:58 +0100, Linus Torvalds wrote:
>>
>> And I didn't think about it or double-check, because the errors that
>> then followed later _looked_ like that TX power failing that I thought
>> hadn't happened.
>
> Yeah, it could be something already got stuck there, hard to say.
>
>>> Since we see that something actually did an rfkill operation. Did you
>>> push a button there?
>>
>> No, I tried to turn off and turn on Wifi manually (no button, just the
>> settings panel).
>
> That does usually also cause rfkill, so that explains how we got down
> this particular code path.
>
>> I didn't notice the WARN_ON(), I just noticed that there was no
>> networking, and "turn it off and on again" is obviously the first
>> thing to try ;)
>
> :-)
>
>> Sep 11 10:27:13 xps13 kernel: WARNING: CPU: 4 PID: 1246 at
>> net/mac80211/sta_info.c:1057 __sta_info_destroy_part2+0x147/0x150
>> [mac80211]
>>
>> but if you want full logs I can send them in private to you.
>
> No, it's fine, though maybe Kalle does - he was stepping out for a while
> but said he'd look later.
>
> This is the interesting time - 10:27:13 we get one of the first
> failures. Really the first one was this:
>
>> Sep 11 10:27:07 xps13 kernel: ath10k_pci 0000:02:00.0: wmi command 16387 timeout, restarting hardware
>
>
>> I do suspect it's atheros and suspend/resume or something. The
>> wireless clearly worked for a while after the resume, but then at some
>> point it stopped.
>
> I'm not really sure it's related to suspend/resume at all, the firmware
> seems to just have gotten stuck, and the device and firmware most likely
> got reset over the suspend/resume anyway.
>
>>> The only explanation I therefore have is that something is just taking
>>> *forever* in that code path, hence my question about timing information
>>> on the logs.
>>
>> Yeah, maybe it would time out everything eventually. But not for a
>> long time. It hadn't cleared up by
>>
>> Sep 11 10:36:21 xps13 gnome-session-f[6837]: gnome-session-failed:
>> Fatal IO error 0 (Success) on X server :0.
>
> Ok, that's way longer than I would have guessed even! That's over 9
> minutes, that'd be close to 200 commands having to be issued and timing
> out ...
>
> I don't know. What I wrote before is basically all I can say, I think
> the driver gets stuck somewhere waiting for the device "forever", and
> the stack just doesn't get to release the lock, causing all the follow-
> up problems.
It looks to me like the ath10k firmware is not responding to commands and/or
is out of its WMI tx credits. The code often takes a lock and then blocks for up to 3
or so seconds waiting for a response from the firmware, and the mac80211 calling
code is often already holding rtnl. Pretty much every mac80211 call will cause a
WMI message and thus potentially hit this timeout.
This can easily cause rtnl to be held for 3 seconds, but after that, I believe
upstream ath10k will now time out and kill the firmware and restart. (I run
a significantly modified ath10k driver, and that is how mine works, at least.)
In this case, it looks like restarting the firmware/NIC failed, and I guess
that must get it in a state where it is still blocking and trying to talk
to the firmware? Or maybe deadlock down inside ath10k driver.
For what it's worth, we see that WARN_ON often when ath10k firmware crashes, but it
seems to not be a big deal and the system normally recovers fine.
Out of curiosity, I'm interested to know what ath10k NIC chipset this is from.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH] mac80211: Do not send Layer 2 Update frame before authorization
From: Jouni Malinen @ 2019-09-11 13:03 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, David Miller, netdev, Jouni Malinen
The Layer 2 Update frame is used to update bridges when a station roams
to another AP even if that STA does not transmit any frames after the
reassociation. This behavior was described in IEEE Std 802.11F-2003 as
something that would happen based on MLME-ASSOCIATE.indication, i.e.,
before completing 4-way handshake. However, this IEEE trial-use
recommended practice document was published before RSN (IEEE Std
802.11i-2004) and as such, did not consider RSN use cases. Furthermore,
IEEE Std 802.11F-2003 was withdrawn in 2006 and as such, has not been
maintained amd should not be used anymore.
Sending out the Layer 2 Update frame immediately after association is
fine for open networks (and also when using SAE, FT protocol, or FILS
authentication when the station is actually authenticated by the time
association completes). However, it is not appropriate for cases where
RSN is used with PSK or EAP authentication since the station is actually
fully authenticated only once the 4-way handshake completes after
authentication and attackers might be able to use the unauthenticated
triggering of Layer 2 Update frame transmission to disrupt bridge
behavior.
Fix this by postponing transmission of the Layer 2 Update frame from
station entry addition to the point when the station entry is marked
authorized. Similarly, send out the VLAN binding update only if the STA
entry has already been authorized.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
---
net/mac80211/cfg.c | 14 ++++----------
net/mac80211/sta_info.c | 4 ++++
2 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index ed56b0c6fe19..817f37b64eb5 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1532,7 +1532,6 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
struct sta_info *sta;
struct ieee80211_sub_if_data *sdata;
int err;
- int layer2_update;
if (params->vlan) {
sdata = IEEE80211_DEV_TO_SUB_IF(params->vlan);
@@ -1575,18 +1574,12 @@ static int ieee80211_add_station(struct wiphy *wiphy, struct net_device *dev,
test_sta_flag(sta, WLAN_STA_ASSOC))
rate_control_rate_init(sta);
- layer2_update = sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
- sdata->vif.type == NL80211_IFTYPE_AP;
-
err = sta_info_insert_rcu(sta);
if (err) {
rcu_read_unlock();
return err;
}
- if (layer2_update)
- cfg80211_send_layer2_update(sta->sdata->dev, sta->sta.addr);
-
rcu_read_unlock();
return 0;
@@ -1684,10 +1677,11 @@ static int ieee80211_change_station(struct wiphy *wiphy,
sta->sdata = vlansdata;
ieee80211_check_fast_xmit(sta);
- if (test_sta_flag(sta, WLAN_STA_AUTHORIZED))
+ if (test_sta_flag(sta, WLAN_STA_AUTHORIZED)) {
ieee80211_vif_inc_num_mcast(sta->sdata);
-
- cfg80211_send_layer2_update(sta->sdata->dev, sta->sta.addr);
+ cfg80211_send_layer2_update(sta->sdata->dev,
+ sta->sta.addr);
+ }
}
err = sta_apply_parameters(local, sta, params);
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index df553070206c..bd11fef2139f 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -1979,6 +1979,10 @@ int sta_info_move_state(struct sta_info *sta,
ieee80211_check_fast_xmit(sta);
ieee80211_check_fast_rx(sta);
}
+ if (sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
+ sta->sdata->vif.type == NL80211_IFTYPE_AP)
+ cfg80211_send_layer2_update(sta->sdata->dev,
+ sta->sta.addr);
break;
default:
break;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2] vhost: block speculation of translated descriptors
From: Michael S. Tsirkin @ 2019-09-11 13:03 UTC (permalink / raw)
To: Michal Hocko; +Cc: linux-kernel, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <20190911123316.GX4023@dhcp22.suse.cz>
On Wed, Sep 11, 2019 at 02:33:16PM +0200, Michal Hocko wrote:
> On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> > On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> > > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > > > iovec addresses coming from vhost are assumed to be
> > > > pre-validated, but in fact can be speculated to a value
> > > > out of range.
> > > >
> > > > Userspace address are later validated with array_index_nospec so we can
> > > > be sure kernel info does not leak through these addresses, but vhost
> > > > must also not leak userspace info outside the allowed memory table to
> > > > guests.
> > > >
> > > > Following the defence in depth principle, make sure
> > > > the address is not validated out of node range.
> > > >
> > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > Acked-by: Jason Wang <jasowang@redhat.com>
> > > > Tested-by: Jason Wang <jasowang@redhat.com>
> > >
> > > no need to mark fo stable? Other spectre fixes tend to be backported
> > > even when the security implications are not really clear. The risk
> > > should be low and better to be covered in case.
> >
> > This is not really a fix - more a defence in depth thing,
> > quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd
> > x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
> > in scope.
> >
> > That one doesn't seem to be tagged for stable. Was it queued
> > there in practice?
>
> not marked for stable but it went in. At least to 4.4.
So I guess the answer is I don't know. If you feel it's
justified, then sure, feel free to forward.
--
MST
^ permalink raw reply
* Re: [PATCH net-next 5/5] sctp: add spt_pathcpthld in struct sctp_paddrthlds
From: Marcelo Ricardo Leitner @ 2019-09-11 12:56 UTC (permalink / raw)
To: Xin Long
Cc: David Laight, network dev, linux-sctp@vger.kernel.org,
Neil Horman, davem@davemloft.net
In-Reply-To: <CADvbK_dqNas+vwP2t3LqWyabNnzRDO=PZPe4p+zE-vQJTnfKpA@mail.gmail.com>
On Wed, Sep 11, 2019 at 05:38:33PM +0800, Xin Long wrote:
> On Wed, Sep 11, 2019 at 5:21 PM Xin Long <lucien.xin@gmail.com> wrote:
> >
> > On Wed, Sep 11, 2019 at 5:03 PM David Laight <David.Laight@aculab.com> wrote:
> > >
> > > From: Xin Long [mailto:lucien.xin@gmail.com]
> > > > Sent: 11 September 2019 09:52
> > > > On Tue, Sep 10, 2019 at 9:19 PM David Laight <David.Laight@aculab.com> wrote:
> > > > >
> > > > > From: Xin Long
> > > > > > Sent: 09 September 2019 08:57
> > > > > > Section 7.2 of rfc7829: "Peer Address Thresholds (SCTP_PEER_ADDR_THLDS)
> > > > > > Socket Option" extends 'struct sctp_paddrthlds' with 'spt_pathcpthld'
> > > > > > added to allow a user to change ps_retrans per sock/asoc/transport, as
> > > > > > other 2 paddrthlds: pf_retrans, pathmaxrxt.
> > > > > >
> > > > > > Note that ps_retrans is not allowed to be greater than pf_retrans.
> > > > > >
> > > > > > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > > > > > ---
> > > > > > include/uapi/linux/sctp.h | 1 +
> > > > > > net/sctp/socket.c | 10 ++++++++++
> > > > > > 2 files changed, 11 insertions(+)
> > > > > >
> > > > > > diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> > > > > > index a15cc28..dfd81e1 100644
> > > > > > --- a/include/uapi/linux/sctp.h
> > > > > > +++ b/include/uapi/linux/sctp.h
> > > > > > @@ -1069,6 +1069,7 @@ struct sctp_paddrthlds {
> > > > > > struct sockaddr_storage spt_address;
> > > > > > __u16 spt_pathmaxrxt;
> > > > > > __u16 spt_pathpfthld;
> > > > > > + __u16 spt_pathcpthld;
> > > > > > };
> > > > > >
> > > > > > /*
> > > > > > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > > > > > index 5e2098b..5b9774d 100644
> > > > > > --- a/net/sctp/socket.c
> > > > > > +++ b/net/sctp/socket.c
> > > > > > @@ -3954,6 +3954,9 @@ static int sctp_setsockopt_paddr_thresholds(struct sock *sk,
> > > > >
> > > > > This code does:
> > > > > if (optlen < sizeof(struct sctp_paddrthlds))
> > > > > return -EINVAL;
> > > > here will become:
> > > >
> > > > if (optlen >= sizeof(struct sctp_paddrthlds)) {
> > > > optlen = sizeof(struct sctp_paddrthlds);
> > > > } else if (optlen >= ALIGN(offsetof(struct sctp_paddrthlds,
> > > > spt_pathcpthld), 4))
> > > > optlen = ALIGN(offsetof(struct sctp_paddrthlds,
> > > > spt_pathcpthld), 4);
> > > > val.spt_pathcpthld = 0xffff;
> > > > else {
> > > > return -EINVAL;
> > > > }
> > >
> > > Hmmm...
> > > If the kernel has to default 'val.spt_pathcpthld = 0xffff'
> > > then recompiling an existing application with the new uapi
> > > header is going to lead to very unexpected behaviour.
> > >
> > > The best you can hope for is that the application memset the
> > > structure to zero.
> > > But more likely it is 'random' on-stack data.
> > 0xffff is a value to disable the feature 'Primary Path Switchover'.
> > you're right that user might set it to zero unexpectly with their
> > old application rebuilt.
> >
> > A safer way is to introduce "sysctl net.sctp.ps_retrans", it won't
> > matter if users set spt_pathcpthld properly when they're not aware
> > of this feature, like "sysctl net.sctp.pF_retrans". Looks better?
> Sorry for confusing, "sysctl net.sctp.ps_retrans" is already there
> (its value is 0xffff by default),
> we just need to do this in sctp_setsockopt_paddr_thresholds():
>
> if (copy_from_user(&val, (struct sctp_paddrthlds __user *)optval,
> optlen))
> return -EFAULT;
>
> if (sock_net(sk)->sctp.ps_retrans == 0xffff)
> val.spt_pathcpthld = 0xffff;
I'm confused with the snippets, but if I got them right, this is after
dealing with proper len and could leave val.spt_pathcpthld
uninitialized if the application used the old format and sysctl is !=
0xffff.
>
> if (val.spt_pathpfthld > val.spt_pathcpthld)
> return -EINVAL;
>
> >
> > >
> > > David
> > >
> > > -
> > > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> > > Registration No: 1397386 (Wales)
>
^ permalink raw reply
* Re: [PATCH v2] vhost: block speculation of translated descriptors
From: Michal Hocko @ 2019-09-11 12:33 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <20190911082236-mutt-send-email-mst@kernel.org>
On Wed 11-09-19 08:25:03, Michael S. Tsirkin wrote:
> On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > > iovec addresses coming from vhost are assumed to be
> > > pre-validated, but in fact can be speculated to a value
> > > out of range.
> > >
> > > Userspace address are later validated with array_index_nospec so we can
> > > be sure kernel info does not leak through these addresses, but vhost
> > > must also not leak userspace info outside the allowed memory table to
> > > guests.
> > >
> > > Following the defence in depth principle, make sure
> > > the address is not validated out of node range.
> > >
> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > Acked-by: Jason Wang <jasowang@redhat.com>
> > > Tested-by: Jason Wang <jasowang@redhat.com>
> >
> > no need to mark fo stable? Other spectre fixes tend to be backported
> > even when the security implications are not really clear. The risk
> > should be low and better to be covered in case.
>
> This is not really a fix - more a defence in depth thing,
> quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd
> x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
> in scope.
>
> That one doesn't seem to be tagged for stable. Was it queued
> there in practice?
not marked for stable but it went in. At least to 4.4.
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* Re: [PATCH 6/7] net: dsa: mv88e6xxx: add egress rate limiting
From: kbuild test robot @ 2019-09-11 12:26 UTC (permalink / raw)
To: Robert Beckett
Cc: kbuild-all, netdev, Robert Beckett, Andrew Lunn, Vivien Didelot,
Florian Fainelli, David S. Miller
In-Reply-To: <20190910154238.9155-7-bob.beckett@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 5217 bytes --]
Hi Robert,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc8 next-20190904]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Robert-Beckett/net-dsa-mv88e6xxx-features-to-handle-network-storms/20190911-142233
config: x86_64-fedora-25 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-11) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
>> drivers/net//dsa/mv88e6xxx/chip.c:3529:31: error: 'mv88e6097_port_egress_rate_limiting' undeclared here (not in a function); did you mean 'mv88e6xxx_port_egress_rate_limiting'?
.port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mv88e6xxx_port_egress_rate_limiting
vim +3529 drivers/net//dsa/mv88e6xxx/chip.c
b3469dd8adade1 Vivien Didelot 2016-09-29 3510
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3511 static const struct mv88e6xxx_ops mv88e6250_ops = {
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3512 /* MV88E6XXX_FAMILY_6250 */
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3513 .ieee_pri_map = mv88e6250_g1_ieee_pri_map,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3514 .ip_pri_map = mv88e6085_g1_ip_pri_map,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3515 .irl_init_all = mv88e6352_g2_irl_init_all,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3516 .get_eeprom = mv88e6xxx_g2_get_eeprom16,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3517 .set_eeprom = mv88e6xxx_g2_set_eeprom16,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3518 .set_switch_mac = mv88e6xxx_g2_set_switch_mac,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3519 .phy_read = mv88e6xxx_g2_smi_phy_read,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3520 .phy_write = mv88e6xxx_g2_smi_phy_write,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3521 .port_set_link = mv88e6xxx_port_set_link,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3522 .port_set_duplex = mv88e6xxx_port_set_duplex,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3523 .port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3524 .port_set_speed = mv88e6250_port_set_speed,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3525 .port_tag_remap = mv88e6095_port_tag_remap,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3526 .port_set_frame_mode = mv88e6351_port_set_frame_mode,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3527 .port_set_egress_floods = mv88e6352_port_set_egress_floods,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3528 .port_set_ether_type = mv88e6351_port_set_ether_type,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 @3529 .port_egress_rate_limiting = mv88e6097_port_egress_rate_limiting,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3530 .port_pause_limit = mv88e6097_port_pause_limit,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3531 .port_disable_pri_override = mv88e6xxx_port_disable_pri_override,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3532 .port_link_state = mv88e6250_port_link_state,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3533 .stats_snapshot = mv88e6320_g1_stats_snapshot,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3534 .stats_set_histogram = mv88e6095_g1_stats_set_histogram,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3535 .stats_get_sset_count = mv88e6250_stats_get_sset_count,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3536 .stats_get_strings = mv88e6250_stats_get_strings,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3537 .stats_get_stats = mv88e6250_stats_get_stats,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3538 .set_cpu_port = mv88e6095_g1_set_cpu_port,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3539 .set_egress_port = mv88e6095_g1_set_egress_port,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3540 .watchdog_ops = &mv88e6250_watchdog_ops,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3541 .mgmt_rsvd2cpu = mv88e6352_g2_mgmt_rsvd2cpu,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3542 .pot_clear = mv88e6xxx_g2_pot_clear,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3543 .reset = mv88e6250_g1_reset,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3544 .vtu_getnext = mv88e6250_g1_vtu_getnext,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3545 .vtu_loadpurge = mv88e6250_g1_vtu_loadpurge,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3546 .phylink_validate = mv88e6065_phylink_validate,
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3547 };
1f71836f5d96e4 Rasmus Villemoes 2019-06-04 3548
:::::: The code at line 3529 was first introduced by commit
:::::: 1f71836f5d96e4c87fad16db86d324bee47e1d30 net: dsa: mv88e6xxx: add support for mv88e6250
:::::: TO: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 50818 bytes --]
^ permalink raw reply
* Re: [PATCH v2] vhost: block speculation of translated descriptors
From: Michael S. Tsirkin @ 2019-09-11 12:25 UTC (permalink / raw)
To: Michal Hocko; +Cc: linux-kernel, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <20190911121628.GT4023@dhcp22.suse.cz>
On Wed, Sep 11, 2019 at 02:16:28PM +0200, Michal Hocko wrote:
> On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> > iovec addresses coming from vhost are assumed to be
> > pre-validated, but in fact can be speculated to a value
> > out of range.
> >
> > Userspace address are later validated with array_index_nospec so we can
> > be sure kernel info does not leak through these addresses, but vhost
> > must also not leak userspace info outside the allowed memory table to
> > guests.
> >
> > Following the defence in depth principle, make sure
> > the address is not validated out of node range.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > Acked-by: Jason Wang <jasowang@redhat.com>
> > Tested-by: Jason Wang <jasowang@redhat.com>
>
> no need to mark fo stable? Other spectre fixes tend to be backported
> even when the security implications are not really clear. The risk
> should be low and better to be covered in case.
This is not really a fix - more a defence in depth thing,
quite similar to e.g. commit b3bbfb3fb5d25776b8e3f361d2eedaabb0b496cd
x86: Introduce __uaccess_begin_nospec() and uaccess_try_nospec
in scope.
That one doesn't seem to be tagged for stable. Was it queued
there in practice?
> > ---
> >
> > changes from v1: fix build on 32 bit
> >
> > drivers/vhost/vhost.c | 6 ++++--
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> > index 5dc174ac8cac..34ea219936e3 100644
> > --- a/drivers/vhost/vhost.c
> > +++ b/drivers/vhost/vhost.c
> > @@ -2071,8 +2071,10 @@ static int translate_desc(struct vhost_virtqueue *vq, u64 addr, u32 len,
> > _iov = iov + ret;
> > size = node->size - addr + node->start;
> > _iov->iov_len = min((u64)len - s, size);
> > - _iov->iov_base = (void __user *)(unsigned long)
> > - (node->userspace_addr + addr - node->start);
> > + _iov->iov_base = (void __user *)
> > + ((unsigned long)node->userspace_addr +
> > + array_index_nospec((unsigned long)(addr - node->start),
> > + node->size));
> > s += size;
> > addr += size;
> > ++ret;
> > --
> > MST
>
> --
> Michal Hocko
> SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] vhost: block speculation of translated descriptors
From: Michal Hocko @ 2019-09-11 12:16 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: linux-kernel, Jason Wang, kvm, virtualization, netdev
In-Reply-To: <20190911120908.28410-1-mst@redhat.com>
On Wed 11-09-19 08:10:00, Michael S. Tsirkin wrote:
> iovec addresses coming from vhost are assumed to be
> pre-validated, but in fact can be speculated to a value
> out of range.
>
> Userspace address are later validated with array_index_nospec so we can
> be sure kernel info does not leak through these addresses, but vhost
> must also not leak userspace info outside the allowed memory table to
> guests.
>
> Following the defence in depth principle, make sure
> the address is not validated out of node range.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Acked-by: Jason Wang <jasowang@redhat.com>
> Tested-by: Jason Wang <jasowang@redhat.com>
no need to mark fo stable? Other spectre fixes tend to be backported
even when the security implications are not really clear. The risk
should be low and better to be covered in case.
> ---
>
> changes from v1: fix build on 32 bit
>
> drivers/vhost/vhost.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 5dc174ac8cac..34ea219936e3 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -2071,8 +2071,10 @@ static int translate_desc(struct vhost_virtqueue *vq, u64 addr, u32 len,
> _iov = iov + ret;
> size = node->size - addr + node->start;
> _iov->iov_len = min((u64)len - s, size);
> - _iov->iov_base = (void __user *)(unsigned long)
> - (node->userspace_addr + addr - node->start);
> + _iov->iov_base = (void __user *)
> + ((unsigned long)node->userspace_addr +
> + array_index_nospec((unsigned long)(addr - node->start),
> + node->size));
> s += size;
> addr += size;
> ++ret;
> --
> MST
--
Michal Hocko
SUSE Labs
^ permalink raw reply
* [PATCH v2] vhost: block speculation of translated descriptors
From: Michael S. Tsirkin @ 2019-09-11 12:10 UTC (permalink / raw)
To: linux-kernel; +Cc: Jason Wang, kvm, virtualization, netdev
iovec addresses coming from vhost are assumed to be
pre-validated, but in fact can be speculated to a value
out of range.
Userspace address are later validated with array_index_nospec so we can
be sure kernel info does not leak through these addresses, but vhost
must also not leak userspace info outside the allowed memory table to
guests.
Following the defence in depth principle, make sure
the address is not validated out of node range.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Tested-by: Jason Wang <jasowang@redhat.com>
---
changes from v1: fix build on 32 bit
drivers/vhost/vhost.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 5dc174ac8cac..34ea219936e3 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2071,8 +2071,10 @@ static int translate_desc(struct vhost_virtqueue *vq, u64 addr, u32 len,
_iov = iov + ret;
size = node->size - addr + node->start;
_iov->iov_len = min((u64)len - s, size);
- _iov->iov_base = (void __user *)(unsigned long)
- (node->userspace_addr + addr - node->start);
+ _iov->iov_base = (void __user *)
+ ((unsigned long)node->userspace_addr +
+ array_index_nospec((unsigned long)(addr - node->start),
+ node->size));
s += size;
addr += size;
++ret;
--
MST
^ permalink raw reply related
* Re: [PATCH] bpf: validate bpf_func when BPF_JIT is enabled
From: Toke Høiland-Jørgensen @ 2019-09-11 12:09 UTC (permalink / raw)
To: Björn Töpel, Yonghong Song, Sami Tolvanen
Cc: Alexei Starovoitov, Daniel Borkmann, Kees Cook, Martin Lau,
Song Liu, netdev@vger.kernel.org, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org, Jesper Dangaard Brouer
In-Reply-To: <fd8b6f04-3902-12e9-eab1-fa85b7e44dd5@intel.com>
Björn Töpel <bjorn.topel@intel.com> writes:
> On 2019-09-11 09:42, Yonghong Song wrote:
>> I am not an expert in XDP testing. Toke, Björn, could you give some
>> suggestions what to test for XDP performance here?
>
> I ran the "xdp_rxq_info" sample with and without Sami's patch:
Thanks for doing this!
> $ sudo ./xdp_rxq_info --dev enp134s0f0 --action XDP_DROP
>
> Before:
>
> Running XDP on dev:enp134s0f0 (ifindex:6) action:XDP_DROP options:no_touch
> XDP stats CPU pps issue-pps
> XDP-RX CPU 20 23923874 0
> XDP-RX CPU total 23923874
>
> RXQ stats RXQ:CPU pps issue-pps
> rx_queue_index 20:20 23923878 0
> rx_queue_index 20:sum 23923878
>
> After Sami's patch:
>
> Running XDP on dev:enp134s0f0 (ifindex:6) action:XDP_DROP options:no_touch
> XDP stats CPU pps issue-pps
> XDP-RX CPU 20 22998700 0
> XDP-RX CPU total 22998700
>
> RXQ stats RXQ:CPU pps issue-pps
> rx_queue_index 20:20 22998705 0
> rx_queue_index 20:sum 22998705
>
>
> So, roughly ~4% for this somewhat naive scenario.
Or (1/22998700 - 1/23923874) * 10**9 == 1.7 nanoseconds of overhead.
I guess that is not *too* bad; but it's still chipping away at
performance; anything we could do to lower the overhead?
-Toke
^ permalink raw reply
* Re: VRF Issue Since kernel 5
From: Gowen @ 2019-09-11 11:49 UTC (permalink / raw)
To: David Ahern, Alexis Bauvin; +Cc: netdev@vger.kernel.org
In-Reply-To: <CWLP265MB15544E2F2303FA2D0F76B7F5FDB10@CWLP265MB1554.GBRP265.PROD.OUTLOOK.COM>
[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]
previously mentioned attchements
From: Gowen <gowen@potatocomputing.co.uk>
Sent: 11 September 2019 12:19
To: David Ahern <dsahern@gmail.com>; Alexis Bauvin <abauvin@online.net>
Cc: netdev@vger.kernel.org <netdev@vger.kernel.org>
Subject: Re: VRF Issue Since kernel 5
Hi there,
Your perf command:
isc-worker0000 20261 [000] 2215.013849: fib:fib_table_lookup: table 10 oif 0 iif 0 proto 0 0.0.0.0/0 -> 127.0.0.1/0 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
isc-worker0000 20261 [000] 2215.013915: fib:fib_table_lookup: table 10 oif 4 iif 1 proto 17 0.0.0.0/52138 -> 127.0.0.53/53 tos 0 scope 0 flags 4 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
isc-worker0000 20261 [000] 2220.014006: fib:fib_table_lookup: table 10 oif 4 iif 1 proto 17 0.0.0.0/52138 -> 127.0.0.53/53 tos 0 scope 0 flags 4 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
Also I set all iptables to policy ACCEPT and flushed the rules, enabled forwarding, checked the sysctl settings are all '1'. I've looked at tracing DNS through the iptables and I see that DNS uses a loopback interface as source and destination - this would
be odd on a Cisco box but having looked around this appears to be normal?
I also gathered an strace of updating the package cache as well as a perf of the same command - will send if interested (is more verbose and not sure if the spam filter will block it)
Gareth
From: Gowen
Sent: 11 September 2019 06:09
To: David Ahern <dsahern@gmail.com>; Alexis Bauvin <abauvin@online.net>
Cc: netdev@vger.kernel.org <netdev@vger.kernel.org>
Subject: RE: VRF Issue Since kernel 5
Thanks for the link - that's really useful. I did re-order ip rules Friday (I think) - no change
-----Original Message-----
From: David Ahern <dsahern@gmail.com>
Sent: 10 September 2019 17:36
To: Alexis Bauvin <abauvin@online.net>; Gowen <gowen@potatocomputing.co.uk>
Cc: netdev@vger.kernel.org
Subject: Re: VRF Issue Since kernel 5
On 9/9/19 1:01 PM, Alexis Bauvin wrote:
> Could you try swapping the local and l3mdev rules?
>
> `ip rule del pref 0; ip rule add from all lookup local pref 1001`
yes, the rules should be re-ordered so that local rule is after l3mdev rule (VRF is implemented as policy routing). In general, I would reverse the order of those commands to ensure no breakage.
Also, 5.0 I think it was (too many kernel versions) added a new l3mdev sysctl (raw_l3mdev_accept). Check all 3 of them and nmake sure they are set properly for your use case.
These slides do not cover 5.0 changes but are still the best collection of notes on VRF:
http://schd.ws/hosted_files/ossna2017/fe/vrf-tutorial-oss.pdf
[-- Attachment #2: perfAptUpdate.txt --]
[-- Type: text/plain, Size: 26235 bytes --]
sudo 25916 [000] 4124.775681: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/47817 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
sudo 25916 [000] 4124.775699: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/47817 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
sudo 25916 [000] 4124.776123: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/33336 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
sudo 25916 [000] 4124.776125: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/33336 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
sudo 25916 [000] 4124.776530: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/38530 -> 10.24.12.10/0 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
sudo 25916 [000] 4124.776532: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/38530 -> 10.24.12.10/0 tos 0 scope 0 flags 0 ==> dev eth1 gw 0.0.0.0 src 10.24.12.9 err 0
sudo 25916 [000] 4124.776533: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.9/38530 -> 10.24.12.10/0 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
sudo 25916 [000] 4124.776533: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.9/38530 -> 10.24.12.10/0 tos 0 scope 0 flags 0 ==> dev eth1 gw 0.0.0.0 src 10.24.12.9 err 0
sudo 25916 [000] 4124.776538: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/51581 -> 10.24.12.9/0 tos 0 scope 0 flags 0 ==> dev eth1 gw 0.0.0.0 src 10.24.12.9 err 0
sudo 25916 [000] 4124.776539: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.9/51581 -> 10.24.12.9/0 tos 0 scope 0 flags 0 ==> dev eth1 gw 0.0.0.0 src 10.24.12.9 err 0
http 25921 [001] 4124.841213: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/37649 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25921 [001] 4124.841216: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/37649 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25921 [001] 4124.841719: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/48658 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25921 [001] 4124.841721: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/48658 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25920 [000] 4124.841776: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/58750 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25920 [000] 4124.841777: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/58750 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25920 [000] 4124.842489: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/38137 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25920 [000] 4124.842491: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/38137 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25922 [000] 4124.843247: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/45896 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25922 [000] 4124.843249: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/45896 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25921 [000] 4124.869712: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/40647 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869714: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/40647 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869715: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/40647 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869715: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/40647 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869720: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/59464 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869720: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/59464 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869721: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/59464 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869721: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/59464 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869724: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/34526 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869724: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/34526 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869725: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/34526 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869725: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/34526 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869728: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/39702 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869728: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/39702 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869729: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/39702 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869729: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/39702 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869732: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/43935 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869732: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/43935 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869733: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/43935 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869733: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/43935 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869736: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/33215 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869736: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/33215 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869754: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/33215 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869755: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/33215 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869758: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/49179 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869758: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/49179 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869759: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/49179 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869759: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/49179 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869762: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/46951 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869762: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/46951 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869763: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/46951 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869763: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/46951 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869766: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/57985 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869766: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/57985 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869767: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/57985 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869767: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/57985 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869770: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/34612 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869771: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 0.0.0.0/34612 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869771: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 10.24.12.10/34612 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869771: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 17 10.24.12.10/34612 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869812: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869813: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869814: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869814: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4124.869818: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/58264 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4124.869819: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/58264 -> 91.189.91.26/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25922 [000] 4124.871436: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 0.0.0.0/35659 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25922 [000] 4124.871437: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 17 127.0.0.1/35659 -> 127.0.0.53/53 tos 0 scope 0 flags 0 ==> dev lo gw 0.0.0.0 src 127.0.0.1 err 0
http 25920 [000] 4124.872626: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.95.83/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25920 [000] 4124.872627: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.95.83/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25920 [000] 4124.872644: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.95.83/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25920 [000] 4124.872645: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.95.83/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25920 [000] 4124.872647: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/37810 -> 91.189.95.83/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25920 [000] 4124.872648: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/37810 -> 91.189.95.83/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25922 [000] 4125.053166: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 51.140.0.211/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25922 [000] 4125.053169: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 51.140.0.211/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25922 [000] 4125.053171: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 51.140.0.211/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25922 [000] 4125.053172: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 51.140.0.211/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25922 [000] 4125.053175: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/46538 -> 51.140.0.211/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25922 [000] 4125.053176: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/46538 -> 51.140.0.211/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.120263: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.120265: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.120267: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.120268: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.120271: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/50938 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.120272: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/50938 -> 91.189.88.149/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.370745: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.370749: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.370751: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.370752: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.370756: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/55830 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.370757: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/55830 -> 91.189.88.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.621209: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.621212: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.621215: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.621216: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.621219: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/42472 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.621220: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/42472 -> 91.189.88.174/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.871668: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.871671: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.871673: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.871674: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4125.871676: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/43154 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4125.871677: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/43154 -> 91.189.88.173/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.122165: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.122167: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.122169: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.122169: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.122172: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/36070 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.122172: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/36070 -> 91.189.91.23/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.372690: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.372696: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.372701: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.372703: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.372709: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/37798 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.372711: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/37798 -> 91.189.91.24/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.623146: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.623167: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.623169: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.623170: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.623172: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/57332 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.623173: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/57332 -> 91.189.88.31/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.873604: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.873608: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.873610: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.873610: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4126.873614: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/54374 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4126.873614: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/54374 -> 91.189.91.14/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4127.124045: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4127.124050: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 0.0.0.0/0 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4127.124054: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4127.124056: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/0 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
http 25921 [000] 4127.124062: fib:fib_table_lookup: table 255 oif 0 iif 1 proto 6 10.24.12.10/45496 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev - gw 0.0.0.0 src 0.0.0.0 err -11
http 25921 [000] 4127.124063: fib:fib_table_lookup: table 254 oif 0 iif 1 proto 6 10.24.12.10/45496 -> 91.189.88.162/80 tos 0 scope 0 flags 0 ==> dev eth0 gw 10.24.12.1 src 10.24.12.10 err 0
[-- Attachment #3: straceAptUpdate.txt --]
[-- Type: text/plain, Size: 39294 bytes --]
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
strace: Process 36321 attached
[pid 36321] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=36321, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
strace: Process 36322 attached
[pid 36322] --- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=36320, si_uid=0} ---
[pid 36322] +++ killed by SIGINT +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=36322, si_uid=0, si_status=SIGINT, si_utime=0, si_stime=0} ---
strace: Process 36323 attached
strace: Process 36324 attached
strace: Process 36325 attached
[pid 36324] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36324] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36324] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36324] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36323] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36323] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36324] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36324] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36324] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36324] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36323] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36323] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36324] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 36324] sendto(3, "PN\1\0\0\1\0\0\0\0\0\1\5_http\4_tcp\10security\6ubuntu\3com\0\0!\0\1\0\0)\2\0\0\0\0\0\0\0", 59, MSG_NOSIGNAL, NULL, 0) = 59
[pid 36324] recvfrom(3, "PN\201\203\0\1\0\0\0\0\0\1\5_http\4_tcp\10security\6ubuntu\3com\0\0!\0\1\0\0)\377\326\0\0\0\0\0\0", 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 59
[pid 36324] socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE) = 3
[pid 36324] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
[pid 36324] getsockname(3, {sa_family=AF_NETLINK, nl_pid=36324, nl_groups=00000000}, [12]) = 0
[pid 36324] sendto(3, {{len=20, type=RTM_GETADDR, flags=NLM_F_REQUEST|NLM_F_DUMP, seq=1568192209, pid=0}, {ifa_family=AF_UNSPEC, ...}}, 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20
[pid 36324] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=76, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, {ifa_family=AF_INET, ifa_prefixlen=8, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 127.0.0.1}, {{nla_len=8, nla_type=IFA_LOCAL}, 127.0.0.1}, {{nla_len=7, nla_type=IFA_LABEL}, "lo"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=607, tstamp=607}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("eth0")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 10.24.12.10}, {{nla_len=8, nla_type=IFA_LOCAL}, 10.24.12.10}, {{nla_len=8, nla_type=IFA_BROADCAST}, 10.24.12.255}, {{nla_len=9, nla_type=IFA_LABEL}, "eth0"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1494, tstamp=1494}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("eth1")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 10.24.12.9}, {{nla_len=8, nla_type=IFA_LOCAL}, 10.24.12.9}, {{nla_len=8, nla_type=IFA_BROADCAST}, 10.24.12.255}, {{nla_len=9, nla_type=IFA_LABEL}, "eth1"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1200, tstamp=1200}}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 252
[pid 36324] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, {ifa_family=AF_INET6, ifa_prefixlen=128, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, ::1}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=607, tstamp=607}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("eth0")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, fe80::222:48ff:fe07:ccad}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1490, tstamp=1490}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("eth1")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, fe80::222:48ff:fe07:c96c}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1198, tstamp=1198}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 216
[pid 36324] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=20, type=NLMSG_DONE, flags=NLM_F_MULTI, seq=1568192209, pid=36324}, 0}, iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20
[pid 36324] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
[pid 36324] connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36324] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36324] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
[pid 36323] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 36323] sendto(3, "\247\n\1\0\0\1\0\0\0\0\0\1\5_http\4_tcp\3ppa\tlaunchpad\3net\0\0!\0\1\0\0)\2\0\0\0\0\0\0\0", 57, MSG_NOSIGNAL, NULL, 0) = 57
[pid 36323] recvfrom(3, "\247\n\201\203\0\1\0\0\0\0\0\1\5_http\4_tcp\3ppa\tlaunchpad\3net\0\0!\0\1\0\0)\377\326\0\0\0\0\0\0", 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 57
[pid 36324] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 36324] sendmmsg(3, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="2\331\1\0\0\1\0\0\0\0\0\1\10security\6ubuntu\3com\0\0\1\0\1\0\0)\4\260\0\0\0\0\0\0", iov_len=48}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=48}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\376\336\1\0\0\1\0\0\0\0\0\1\10security\6ubuntu\3com\0\0\34\0\1\0\0)\4\260\0\0\0\0\0\0", iov_len=48}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=48}], 2, MSG_NOSIGNAL) = 2
[pid 36324] recvfrom(3, <unfinished ...>
[pid 36325] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0 <unfinished ...>
[pid 36324] <... recvfrom resumed> "\376\336\201\200\0\1\0\6\0\0\0\1\10security\6ubuntu\3com\0\0\34\0\1\300\f\0\34\0\1\0\0\0\30\0\20 \1\6|\23`\200\1\0\0\0\0\0\0\0!\300\f\0\34\0\1\0\0\0\30\0\20 \1\6|\25`\200\1\0\0\0\0\0\0\0\21\300\f\0\34\0\1\0\0\0\30\0\20 \1\6|\25b\0\0\0\0\0\0\0\0\0\26\300\f\0\34\0\1\0\0\0\30\0\20 \1\6|\23`\200\1\0\0\0\0\0\0\0\27\300\f\0\34\0\1\0\0\0\30\0\20 \1\6|\25b\0\0\0\0\0\0\0\0\0\31\300\f\0\34\0\1\0\0\0\30\0\20 \1\6|\25`\200\1\0\0\0\0\0\0\0\24\0\0)\377\326\0\0\0\0\0\0", 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 216
[pid 36325] <... socket resumed> ) = 3
[pid 36325] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE) = 3
[pid 36325] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0 <unfinished ...>
[pid 36323] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12 <unfinished ...>
[pid 36325] <... socket resumed> ) = 3
[pid 36323] <... bind resumed> ) = 0
[pid 36325] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110 <unfinished ...>
[pid 36323] getsockname(3, <unfinished ...>
[pid 36325] <... connect resumed> ) = -1 ENOENT (No such file or directory)
[pid 36323] <... getsockname resumed> {sa_family=AF_NETLINK, nl_pid=36323, nl_groups=00000000}, [12]) = 0
[pid 36323] sendto(3, {{len=20, type=RTM_GETADDR, flags=NLM_F_REQUEST|NLM_F_DUMP, seq=1568192209, pid=0}, {ifa_family=AF_UNSPEC, ...}}, 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20
[pid 36323] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=76, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, {ifa_family=AF_INET, ifa_prefixlen=8, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 127.0.0.1}, {{nla_len=8, nla_type=IFA_LOCAL}, 127.0.0.1}, {{nla_len=7, nla_type=IFA_LABEL}, "lo"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=607, tstamp=607}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("eth0")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 10.24.12.10}, {{nla_len=8, nla_type=IFA_LOCAL}, 10.24.12.10}, {{nla_len=8, nla_type=IFA_BROADCAST}, 10.24.12.255}, {{nla_len=9, nla_type=IFA_LABEL}, "eth0"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1494, tstamp=1494}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("eth1")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 10.24.12.9}, {{nla_len=8, nla_type=IFA_LOCAL}, 10.24.12.9}, {{nla_len=8, nla_type=IFA_BROADCAST}, 10.24.12.255}, {{nla_len=9, nla_type=IFA_LABEL}, "eth1"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1200, tstamp=1200}}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 252
[pid 36323] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, {ifa_family=AF_INET6, ifa_prefixlen=128, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, ::1}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=607, tstamp=607}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("eth0")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, fe80::222:48ff:fe07:ccad}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1490, tstamp=1490}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("eth1")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, fe80::222:48ff:fe07:c96c}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1198, tstamp=1198}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 216
[pid 36323] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=20, type=NLMSG_DONE, flags=NLM_F_MULTI, seq=1568192209, pid=36323}, 0}, iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20
[pid 36323] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
[pid 36323] connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36323] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36323] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
[pid 36323] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 36323] sendmmsg(3, [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="DN\1\0\0\1\0\0\0\0\0\1\3ppa\tlaunchpad\3net\0\0\1\0\1\0\0)\4\260\0\0\0\0\0\0", iov_len=46}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=46}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\340S\1\0\0\1\0\0\0\0\0\1\3ppa\tlaunchpad\3net\0\0\34\0\1\0\0)\4\260\0\0\0\0\0\0", iov_len=46}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=46}], 2, MSG_NOSIGNAL) = 2
[pid 36323] recvfrom(3, "DN\201\200\0\1\0\1\0\0\0\1\3ppa\tlaunchpad\3net\0\0\1\0\1\300\f\0\1\0\1\0\0\0\n\0\4[\275_S\0\0)\377\326\0\0\0\0\0\0", 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 62
[pid 36323] recvfrom(3, "\340S\201\200\0\1\0\0\0\0\0\1\3ppa\tlaunchpad\3net\0\0\34\0\1\0\0)\377\326\0\0\0\0\0\0", 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 46
[pid 36323] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
[pid 36323] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.95.83")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36325] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36325] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36325] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36325] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36325] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
[pid 36325] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16) = 0
[pid 36325] sendto(3, "\24A\1\0\0\1\0\0\0\0\0\1\5_http\4_tcp\5azure\7archive\6ubuntu\3com\0\0!\0\1\0\0)\2\0\0\0\0\0\0\0", 64, MSG_NOSIGNAL, NULL, 0) = 64
[pid 36325] recvfrom(3, "\24A\201\203\0\1\0\0\0\0\0\1\5_http\4_tcp\5azure\7archive\6ubuntu\3com\0\0!\0\1\0\0)\377\326\0\0\0\0\0\0", 512, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 64
[pid 36325] socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE) = 3
[pid 36325] bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
[pid 36325] getsockname(3, {sa_family=AF_NETLINK, nl_pid=36325, nl_groups=00000000}, [12]) = 0
[pid 36325] sendto(3, {{len=20, type=RTM_GETADDR, flags=NLM_F_REQUEST|NLM_F_DUMP, seq=1568192209, pid=0}, {ifa_family=AF_UNSPEC, ...}}, 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20
[pid 36325] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=76, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, {ifa_family=AF_INET, ifa_prefixlen=8, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 127.0.0.1}, {{nla_len=8, nla_type=IFA_LOCAL}, 127.0.0.1}, {{nla_len=7, nla_type=IFA_LABEL}, "lo"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=607, tstamp=607}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("eth0")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 10.24.12.10}, {{nla_len=8, nla_type=IFA_LOCAL}, 10.24.12.10}, {{nla_len=8, nla_type=IFA_BROADCAST}, 10.24.12.255}, {{nla_len=9, nla_type=IFA_LABEL}, "eth0"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1494, tstamp=1494}}]}, {{len=88, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, {ifa_family=AF_INET, ifa_prefixlen=24, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_UNIVERSE, ifa_index=if_nametoindex("eth1")}, [{{nla_len=8, nla_type=IFA_ADDRESS}, 10.24.12.9}, {{nla_len=8, nla_type=IFA_LOCAL}, 10.24.12.9}, {{nla_len=8, nla_type=IFA_BROADCAST}, 10.24.12.255}, {{nla_len=9, nla_type=IFA_LABEL}, "eth1"}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1200, tstamp=1200}}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 252
[pid 36325] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=[{{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, {ifa_family=AF_INET6, ifa_prefixlen=128, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_HOST, ifa_index=if_nametoindex("lo")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, ::1}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=607, tstamp=607}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("eth0")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, fe80::222:48ff:fe07:ccad}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1490, tstamp=1490}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}, {{len=72, type=RTM_NEWADDR, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK, ifa_index=if_nametoindex("eth1")}, [{{nla_len=20, nla_type=IFA_ADDRESS}, fe80::222:48ff:fe07:c96c}, {{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=1198, tstamp=1198}}, {{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT}]}], iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 216
[pid 36325] recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=20, type=NLMSG_DONE, flags=NLM_F_MULTI, seq=1568192209, pid=36325}, 0}, iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20
[pid 36325] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 4
[pid 36325] connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36325] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
[pid 36325] connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
[pid 36324] recvfrom(3, "2\331\201\200\0\1\0\n\0\0\0\1\10security\6ubuntu\3com\0\0\1\0\1\300\f\0\1\0\1\0\0\0\31\0\4[\275X\30\300\f\0\1\0\1\0\0\0\31\0\4[\275[\32\300\f\0\1\0\1\0\0\0\31\0\4[\275X\255\300\f\0\1\0\1\0\0\0\31\0\4[\275X\256\300\f\0\1\0\1\0\0\0\31\0\4[\275[\30\300\f\0\1\0\1\0\0\0\31\0\4[\275[\27\300\f\0\1\0\1\0\0\0\31\0\4[\275X\242\300\f\0\1\0\1\0\0\0\31\0\4[\275[\16\300\f\0\1\0\1\0\0\0\31\0\4[\275X\225\300\f\0\1\0\1\0\0\0\31\0\4[\275X\37\0\0)\377\326\0\0\0\0\0\0", 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 208
[pid 36324] socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
[pid 36324] connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1360:8001::21", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1560:8001::11", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1562::16", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1360:8001::17", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16 <unfinished ...>
[pid 36325] socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP <unfinished ...>
[pid 36324] <... connect resumed> ) = 0
[pid 36325] <... socket resumed> ) = 3
[pid 36324] connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1562::19", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28 <unfinished ...>
[pid 36325] connect(3, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, 16 <unfinished ...>
[pid 36324] <... connect resumed> ) = -1 ENETUNREACH (Network is unreachable)
[pid 36325] <... connect resumed> ) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1560:8001::14", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28 <unfinished ...>
[pid 36325] sendmmsg(3, <unfinished ...>
[pid 36324] <... connect resumed> ) = -1 ENETUNREACH (Network is unreachable)
[pid 36325] <... sendmmsg resumed> [{msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\346o\1\0\0\1\0\0\0\0\0\1\5azure\7archive\6ubuntu\3com\0\0\1\0\1\0\0)\4\260\0\0\0\0\0\0", iov_len=53}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=53}, {msg_hdr={msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\310w\1\0\0\1\0\0\0\0\0\1\5azure\7archive\6ubuntu\3com\0\0\34\0\1\0\0)\4\260\0\0\0\0\0\0", iov_len=53}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, msg_len=53}], 2, MSG_NOSIGNAL) = 2
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.24")}, 16 <unfinished ...>
[pid 36325] recvfrom(3, <unfinished ...>
[pid 36324] <... connect resumed> ) = 0
[pid 36325] <... recvfrom resumed> "\310w\201\200\0\1\0\2\0\0\0\1\5azure\7archive\6ubuntu\3com\0\0\34\0\1\300\f\0\5\0\1\0\0\0\32\0'\22ubuntu-archive-asm\16trafficmanager\3net\0\3006\0\5\0\1\0\0\0\243\0$\narchive-lb\7uksouth\10cloudapp\5azure\300!\0\0)\377\326\0\0\0\0\0\0", 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 152
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(49655), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.26")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(49028), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.173")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(41881), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.174")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(38464), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.24")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(42203), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.23")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(36741), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.162")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(55074), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.14")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(38765), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.149")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(50952), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] connect(3, {sa_family=AF_UNSPEC, sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 16) = 0
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.31")}, 16) = 0
[pid 36324] getsockname(3, {sa_family=AF_INET6, sin6_port=htons(49783), inet_pton(AF_INET6, "::ffff:10.24.12.10", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
[pid 36324] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.24")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36325] recvfrom(3, "\346o\201\200\0\1\0\3\0\0\0\1\5azure\7archive\6ubuntu\3com\0\0\1\0\1\300\f\0\5\0\1\0\0\0\32\0'\22ubuntu-archive-asm\16trafficmanager\3net\0\3006\0\5\0\1\0\0\0\243\0$\narchive-lb\7uksouth\10cloudapp\5azure\300!\300i\0\1\0\1\0\0\0\n\0\0043\214\0\323\0\0)\377\326\0\0\0\0\0\0", 65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.53")}, [28->16]) = 168
[pid 36325] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
[pid 36325] connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("51.140.0.211")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 4
[pid 36324] connect(4, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1360:8001::21", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 4
[pid 36324] connect(4, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.26")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 5
[pid 36324] connect(5, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1560:8001::11", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 5
[pid 36324] connect(5, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.173")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 6
[pid 36324] connect(6, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1562::16", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
[pid 36324] connect(6, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.174")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 7
[pid 36324] connect(7, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1360:8001::17", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 7
[pid 36324] connect(7, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.24")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 8
[pid 36324] connect(8, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1562::19", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 8
[pid 36324] connect(8, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.23")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP) = 9
[pid 36324] connect(9, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "2001:67c:1560:8001::14", &sin6_addr), sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 9
[pid 36324] connect(9, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.162")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 10
[pid 36324] connect(10, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.91.14")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 11
[pid 36324] connect(11, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.149")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 36324] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 12
[pid 36324] connect(12, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("91.189.88.31")}, 16) = -1 EINPROGRESS (Operation now in progress)
Err:1 http://ppa.launchpad.net/ansible/ansible/ubuntu bionic InRelease
Could not connect to ppa.launchpad.net:80 (91.189.95.83), connection timed out
Err:2 http://azure.archive.ubuntu.com/ubuntu bionic InRelease
Could not connect to azure.archive.ubuntu.com:80 (51.140.0.211), connection timed out
Err:3 http://azure.archive.ubuntu.com/ubuntu bionic-updates InRelease
Unable to connect to azure.archive.ubuntu.com:http:
Err:4 http://azure.archive.ubuntu.com/ubuntu bionic-backports InRelease
Unable to connect to azure.archive.ubuntu.com:http:
Err:5 http://security.ubuntu.com/ubuntu bionic-security InRelease
Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1360:8001::21). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1560:8001::11). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1562::16). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1360:8001::17). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1562::19). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1560:8001::14). - connect (101: Network is unreachable) Could not connect to security.ubuntu.com:80 (91.189.88.24), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.26), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.173), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.174), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.24), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.23), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.162), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.14), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.149), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.31), connection timed out
[pid 36323] --- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=36320, si_uid=0} ---
[pid 36323] +++ exited with 100 +++
[pid 36320] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=36323, si_uid=104, si_status=100, si_utime=0, si_stime=1} ---
[pid 36324] --- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=36320, si_uid=0} ---
[pid 36324] +++ exited with 100 +++
[pid 36320] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=36324, si_uid=104, si_status=100, si_utime=0, si_stime=1} ---
[pid 36325] --- SIGINT {si_signo=SIGINT, si_code=SI_USER, si_pid=36320, si_uid=0} ---
[pid 36325] +++ exited with 100 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=36325, si_uid=104, si_status=100, si_utime=1, si_stime=1} ---
Reading package lists...strace: Process 36394 attached
[pid 36394] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=36394, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
strace: Process 36396 attached
[pid 36396] +++ exited with 0 +++
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=36396, si_uid=0, si_status=0, si_utime=0, si_stime=0} ---
Building dependency tree...
Reading state information...
All packages are up to date.
W: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/dists/bionic/InRelease Could not connect to azure.archive.ubuntu.com:80 (51.140.0.211), connection timed out
W: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/dists/bionic-updates/InRelease Unable to connect to azure.archive.ubuntu.com:http:
W: Failed to fetch http://azure.archive.ubuntu.com/ubuntu/dists/bionic-backports/InRelease Unable to connect to azure.archive.ubuntu.com:http:
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/bionic-security/InRelease Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1360:8001::21). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1560:8001::11). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1562::16). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1360:8001::17). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1562::19). - connect (101: Network is unreachable) Cannot initiate the connection to security.ubuntu.com:80 (2001:67c:1560:8001::14). - connect (101: Network is unreachable) Could not connect to security.ubuntu.com:80 (91.189.88.24), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.26), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.173), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.174), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.24), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.23), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.162), connection timed out Could not connect to security.ubuntu.com:80 (91.189.91.14), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.149), connection timed out Could not connect to security.ubuntu.com:80 (91.189.88.31), connection timed out
W: Failed to fetch http://ppa.launchpad.net/ansible/ansible/ubuntu/dists/bionic/InRelease Could not connect to ppa.launchpad.net:80 (91.189.95.83), connection timed out
W: Some index files failed to download. They have been ignored, or old ones used instead.
+++ exited with 0 +++
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox