From nobody Wed Oct 06 04:09:43 2021 X-Original-To: freebsd-mips@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3035017E30E6 for ; Wed, 6 Oct 2021 04:10:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HPLZf39D2z4ss7 for ; Wed, 6 Oct 2021 04:10:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-qt1-f169.google.com with SMTP id x9so1382649qtv.0 for ; Tue, 05 Oct 2021 21:10:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Srh5wm3xUQCaykqz4FRtnKwzpKIFxQ+DjamNhHsJFfo=; b=nuQgTEhuKh8Hs+NSBkv3PERZ/mjdTgnj6SinJvSH16ln9Ad5Z5NJCR1LX2EIjq6ltO 78rK0Qd2SxjaAFrI4sSkgPnzw0VH9M2qdaID/h8cGnPNxVmi+4O7S5B+omFeDtL7p/TN AnPp/hMaXlqO/ibpA8TYLCG/e2CLjmSvFjgQgwxpipyXLpYixzMwkv8sK1PvH5ODZQWv sZXXhFhkYwSN44LTOIk/T2apf/Iyc8Vvk6bIjaj6IxbkOq8rB5zL7qEPO2pm7njWUYVH E2yOsl5glrzqWQXTHu9tJG1CwHdDJu7F1eg1jQQTrkh6AKZUR+csfYnBTYtaXotK5s7U /Lmw== X-Gm-Message-State: AOAM530B6226g5TKA85n+aLmJ7F+gN0tth6QPycMVpfO3jH1At+69eKP 4r8Gmy52l359kFuJ72GoSO1o08ec7OLVMON6W/sn334c X-Google-Smtp-Source: ABdhPJzBCxFFaPXgYK5KHzjMcqxOUAqfFqzbW4J8Dw3WfwgHNHrrpid17kldEHre7kg/L0xuW/Tywhzk0ycHJHFL10o= X-Received: by 2002:a05:622a:1a92:: with SMTP id s18mr25505001qtc.76.1633493396480; Tue, 05 Oct 2021 21:09:56 -0700 (PDT) List-Id: Porting FreeBSD to MIPS List-Archive: https://lists.freebsd.org/archives/freebsd-mips List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-mips@freebsd.org MIME-Version: 1.0 References: <508487328.1458827.1627872864522.JavaMail.yahoo.ref@mail.yahoo.co.jp> <508487328.1458827.1627872864522.JavaMail.yahoo@mail.yahoo.co.jp> <1808957876.1396650.1627901671994.JavaMail.yahoo@mail.yahoo.co.jp> In-Reply-To: <1808957876.1396650.1627901671994.JavaMail.yahoo@mail.yahoo.co.jp> From: Adrian Chadd Date: Tue, 5 Oct 2021 21:09:43 -0700 Message-ID: Subject: Re: AR9341 internal etherswitch problem. To: Mori Hiroki Cc: "freebsd-mips@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HPLZf39D2z4ss7 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of adrianchadd@gmail.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=adrianchadd@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-mips@freebsd.org]; ARC_NA(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.160.169:from]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[209.85.160.169:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEMAIL_TO(0.00)[yahoo.co.jp]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N hi! sorry i just saw this :( So, there are flags in the QCA switches that can control what kind of traffic floods. They sometimes have it under "security" features. You'd have to look at the datasheet for the internal switch to see. I remember encountering this when doing the initial switch bring-ups; i started noticing that the per-switch behaviour for flooding/learning addresses was subtly different. I don't know if I fixed it on the AR9341. -adrian On Mon, 2 Aug 2021 at 03:54, Mori Hiroki wrote: > > Hi > > I found very strange behavior. > > ARP request is flooding at AR9341 internal switch. > But other tcp packet is not flooding. > > If delete arp table in host and flush mac table on > switchthenping to ar9341 is work. > > But if arp have host and flush mac table on switch > thenping in not work. > > > very strange > > Hiroki Mori > > > > ----- Original Message ----- > > From: Mori Hiroki > > To: "adrian@freebsd.org" > > Cc: "freebsd-mips@freebsd.org" > > Date: 2021/8/2, Mon 11:54 > > Subject: AR9341 internal etherswitch problem. > > > > Hi > > > > I have ethernet switch problem at AR9341 module. > > > > Some time can't not reach this module by ethernet. > > > > I check this problem. I think atu flush make problem. > > > > If do all atu flush then lost table host port mac address. > > > > This is can't reach the module. > > > > Current implementation is flush by cable status change. > > > > I think do not flush any time by host. > > > > Regards > > > > Hiroki Mori > > >