From owner-freebsd-wireless@freebsd.org Sun Apr 17 16:52:29 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26621AED5AD for ; Sun, 17 Apr 2016 16:52:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F29311362 for ; Sun, 17 Apr 2016 16:52:28 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u3HGqSKX037931 for ; Sun, 17 Apr 2016 16:52:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 208860] [net80211]: ieee80211_waitfor_parent() will hang forever if something is enqueued into the taskqueue Date: Sun, 17 Apr 2016 16:52:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: avos@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 16:52:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208860 Bug ID: 208860 Summary: [net80211]: ieee80211_waitfor_parent() will hang forever if something is enqueued into the taskqueue Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: wireless Assignee: freebsd-wireless@FreeBSD.org Reporter: avos@freebsd.org Manual tracing (wlan0 and wlan2 are monitor mode vaps on wpi0): wlan0: wlan0: ieee80211_ioctl: before ieee80211_start_locked() wlan0: start running, 0 vaps running wlan0: ieee80211_start_locked: up parent wpi0 wlan0: ieee80211_ioctl: before ieee80211_waitfor_parent(), wait=3D1 wlan0: ieee80211_waitfor_parent: before taskqueue_block() wlan0: ieee80211_waitfor_parent: ieee80211_draintask(ic, &ic->ic_parent_tas= k); <<< hangs here wlan2: wlan2: ieee80211_ioctl: before ieee80211_start_locked() wlan2: start running, 1 vaps running wlan2: ieee80211_new_state_locked: INIT -> RUN (nrunning 0 nscanning 0) wlan2: ieee80211_ioctl: before ieee80211_waitfor_parent(), wait=3D0 <<< no progress too Since the manpage for taskqueue(9) states > The taskqueue_block() function blocks the taskqueue. It prevents any > enqueued but not running tasks from being executed. and > Note that if taskqueue_drain() is called on a task that is enqueued on a > taskqueue that is blocked by taskqueue_block(), then taskqueue_drain() > can not return until the taskqueue is unblocked. this function will never work as expected (probably, it should set a flag f= or ieee80211_runtask() + call taskqueue_drain_all() instead). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-wireless@freebsd.org Sun Apr 17 18:51:49 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23F65B125CD for ; Sun, 17 Apr 2016 18:51:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 06DB31849 for ; Sun, 17 Apr 2016 18:51:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u3HIpmln013155 for ; Sun, 17 Apr 2016 18:51:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 208860] [net80211]: ieee80211_waitfor_parent() will hang forever if something is enqueued into the taskqueue Date: Sun, 17 Apr 2016 18:51:48 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: adrian@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 18:51:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208860 Adrian Chadd changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |adrian@freebsd.org --- Comment #1 from Adrian Chadd --- Yeah, the whole drain/block/cancel thing really irks me with our taskqueue implementation. If we want to use the taskqueue for driver related things, then we need some way to actually cancel/drain all in a sane way. Otherwise we end up only be= ing able to waitfor_parent on the net80211 tasks, not the driver tasks. It's also unclear whether we should be waiting for the driver taskqueue cal= ls to drain/complete with waitfor_parent. This requires a bunch more thought and planning. I'm open to ideas! --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-wireless@freebsd.org Sun Apr 17 18:56:12 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BAEC7B1270D for ; Sun, 17 Apr 2016 18:56:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8591E1A1F for ; Sun, 17 Apr 2016 18:56:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x231.google.com with SMTP id y9so9155541igg.1 for ; Sun, 17 Apr 2016 11:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-transfer-encoding; bh=u8TjXGI4b13NwZZwxvbAbAi6ZQ6E4FEDcof2iBaFZrE=; b=MhTwT5LFBrHbxODAI/smQdqyL/JUVYMFUVBxB5x4C4XCOCxqQDyAntxAHQj02vuydP HvI4iUMVRWjeLbJucHbrhBwVZUu2de2LlHRnmR2Dm0QBuOkrHFsd3UY1XONmvpVFoJsx 3LVNyvU5+sMbob5ADJCjPxB3txUEUI1uvcB7lvZOWlhzQZYSN9qBHAeV4aJx8+egyrbW dxqyIMLdj6rWrdrx5j6VUgptxsbphKXKt1ZM5zhZbZCYceiMYDAkieO592SY2QwLCCEv YLzG2Aq4JZaQOb+DRSssaCDEaKdFhOpTOz/cUvinBKU3uA0YavKN7pu6ydC/e7CAxcXn S4Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=u8TjXGI4b13NwZZwxvbAbAi6ZQ6E4FEDcof2iBaFZrE=; b=D+5ZlU1VQlSngrl+HNrvrPg/LRbJwBoY7RCVcCtLwkDid+9Qdj4IALhGEIEG8iU4II 7JJ/RaGOptrYun1caKD6vQGzPjSmjgDGdLHmRRFv/lx7GRIxgqb9zBVuZa4D+y7FZHNC djDvNBEhK3P0wPdIZEIljx3LFpFxMjveEE3QlAF9w5RspsnIe6AKkMgEkDq4xIWxFd9e +FOarxHZMk60rk1Mh47yTYKJhPk0+U7DSTF12NGBYeoSfeCTWn5kN7PmAxn0wWTTYQFR z9/fH1P+akPUTbn3WOjAndeFwLOsigwMTiFdnNc5opie2FMIII9njLgOhK8cROJYxWkU zsyA== X-Gm-Message-State: AOPr4FXzABsceixrStblouyfgZVmNUwC9ToCcp958fyad1a6Lk5DRbxvr+rcQnn+9lg8bsvAn+nWvwNe7/ZlcQ== MIME-Version: 1.0 X-Received: by 10.50.103.232 with SMTP id fz8mr14618235igb.61.1460919371902; Sun, 17 Apr 2016 11:56:11 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.14.19 with HTTP; Sun, 17 Apr 2016 11:56:11 -0700 (PDT) In-Reply-To: <1598491542.1788727.1460839447819.JavaMail.yahoo@mail.yahoo.com> References: <1598491542.1788727.1460839447819.JavaMail.yahoo.ref@mail.yahoo.com> <1598491542.1788727.1460839447819.JavaMail.yahoo@mail.yahoo.com> Date: Sun, 17 Apr 2016 11:56:11 -0700 X-Google-Sender-Auth: lJ9SnZ5tGnoW41CKocjq4kcCK1g Message-ID: Subject: Re: Huawei E3372 ( sonera.fi ) From: Adrian Chadd To: Jouni Laakso Cc: "freebsd-wireless@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 18:56:12 -0000 hi! this is cool to know! any ideas why the latency is higher? -a On 16 April 2016 at 13:44, Jouni Laakso via freebsd-wireless wrote: > > > Hello list, > > > I wanted to send this information to help others in their quest of 4G con= nectivity with FreeBSD here at Europes continent and in Finland. Huawei doe= s not include a lot of information about their products. These 4G-network m= odems are usually provided by the subscriberline companies and with their o= wn products. This one was from Sonera (Teliasonera, .se and .fi) here in Fi= nland. > Huawei E3372 seems to be a CDCE device. /boot/loader.conf has to have a l= ine if_cdce_load=3D"YES". Only usb_modeswitch works with this one. Command: > /usr/local/sbin/usb_modeswitch --default-vendor 0x12d1 --default-product = 0x1f01 -J > swithes to the CDCE mode. Device ue0 appears to be configured (with ifcon= fig -command). Using 'dhclient ue0' a network address is found and using th= e address and adding a default router the network interface is usable. An a= dmin HTTP-page can be found from http://192.168.1.1. CDCE has two network i= nterfaces at both ends of USB. Both ends can be configured with their own I= P-address. > ID:s idVendor =3D 0x12d1 idProduct =3D 0x1f01 are switched to ID:s idVe= ndor =3D 0x12d1 idProduct =3D 0x14dc . This seems to be correct since the = connection to the Internet succeeded with cdce. > Using u3g.c:U3G_DEV(HUAWEI, K3372_INIT, U3GINIT_HUAWEISCSI) > Causes the modem to appear as a device id 0x1442 . Using this, only NTP p= ort was listening. Maby this is a ntp mode. Using:U3G_DEV(HUAWEI, E3372_INI= T, U3GINIT_HUAWEISCSI2) > does not give any results. These are the current possibilities if compili= ng a new kernel every time is possible. > It would be easier if a device had only one identification code. Reading = about the different codes from usb_modeswitch list, it is maby clear that t= he service provider can change the device ID:s. This is not very easy to th= e users. If the device was only a modem, it would be usable without the fl= ip-flop states of the modem-devices. ISO image is given with Windows and Li= nux drivers or software and after installing the software, the state become= s a modem state. Possibly with a HTTP-interface to connecto to the Internet= . > Quick test with Linux shows that the latency time is less with Linux. Pre= viously using PPP with these kind of wireless devices, FreeBSD has shown be= st latency times. This is an estimate. Using an external modem (propably Li= nux inside) caused more latency with PPP over the previous 3G link. > > With best regards, > > Jouni L. > _______________________________________________ > freebsd-wireless@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-wireless > To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.or= g" From owner-freebsd-wireless@freebsd.org Sun Apr 17 21:00:41 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A22E6B1218C for ; Sun, 17 Apr 2016 21:00:41 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9960B199E for ; Sun, 17 Apr 2016 21:00:41 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u3HL01M9043394 for ; Sun, 17 Apr 2016 21:00:41 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201604172100.u3HL01M9043394@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-wireless@FreeBSD.org Subject: Problem reports for freebsd-wireless@FreeBSD.org that need special attention Date: Sun, 17 Apr 2016 21:00:41 +0000 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 21:00:41 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 206801 | iwn(4) page fault on netif restart Open | 154598 | [ath] Atheros 5424/2424 can't connect to WPA netw Open | 163312 | [panic] [ath] kernel panic: page fault with ath0 Open | 166190 | [ath] TX hangs and frames stuck in TX queue Open | 166357 | [ath] 802.11n TX stall when the first frame in th Open | 169362 | [ath] AR5416: radar pulse PHY errors sometimes in Open | 169433 | [iwn] iwn(4) doesn't support 6235 chip. 7 problems total for which you should take action. From owner-freebsd-wireless@freebsd.org Sun Apr 17 21:45:59 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89C18B101DF for ; Sun, 17 Apr 2016 21:45:59 +0000 (UTC) (envelope-from jounijl@yahoo.co.uk) Received: from nm40.bullet.mail.ne1.yahoo.com (nm40.bullet.mail.ne1.yahoo.com [98.138.229.33]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 598471959 for ; Sun, 17 Apr 2016 21:45:59 +0000 (UTC) (envelope-from jounijl@yahoo.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1460929552; bh=G+0KUusdD3K9+R/10p0nj3Y1DWqciFOhqUge0wm5coU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Cu6ZQKTXdSeknEwSyksVlykg3kTum7d3bINgtm/CTF4vljazGYjM3EHsAWJUSSDyEofdyuTKE0QyRqc+iwQtudRJEqM97BTM55r4Au11p7H5tkwg5PWdcVejg4ExCeOYDt9ad5awK+5v82ckI/ZFRC3MG2y9liaeacMkm9eztZ11ITD5wgZ8/SH31zU0agFaM5pOwd+vffDJPd4q6RUgn0tg/h6iv2RW6OGXbbNFicKPmih0u84YEl2qhkMZPcmogV8b1kD4t513B1JHinjHcmQjm45d1SKZimVqnH02AA1SCOJKwggOej5WyCIK5ubLaq6aBwHtyalca3C0psjZJQ== Received: from [127.0.0.1] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 17 Apr 2016 21:45:52 -0000 Received: from [98.138.100.103] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 17 Apr 2016 21:42:55 -0000 Received: from [98.139.215.143] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 17 Apr 2016 21:42:55 -0000 Received: from [98.139.212.232] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 17 Apr 2016 21:42:55 -0000 Received: from [127.0.0.1] by omp1041.mail.bf1.yahoo.com with NNFMP; 17 Apr 2016 21:42:55 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 593502.56139.bm@omp1041.mail.bf1.yahoo.com X-YMail-OSG: .jDwz6QVM1ljlLng_u_Qmgqf6NlA5DHwNHFJEA9cGZVG.t0RMyd8k72ney8WyB5 AYpxlIym6GPRyrfra_RH6er3pP5tSxnDtPrOE7IMZS1eGiQDDDU8hzRzAV3bc9t.zu68b6zmlXtf zhHHK9G70_W5Ogm5JoFm9rVqiRvC.suhO7E_QNEx4sKVdJdxOne6K3ChkWz72hNntLJ8nxKo8aj2 XMcesxtufWxJrnUuaLWkQYvELuhckLrV4CkSULD726ueOku0CCnczwS6mMg_XvgU_ECXnSCC4nqo jaSHVqfKB41tjgEVEz_7kOq7H5p1_N9QugBPtLnGOflMKpdfIwh8XN6Mm_oQFVDFw1tGMgaH1APt J3azFJ9BgWPB7OoGgYmC6wlJjmludZUEB736LHNS91dKxNR25J2tJN86pJhTq7_pR84rG6UX.PBR guS6VOaPCVvFOh0TmvMqTgbC5KACoVWo.cVWrVr4w6sZjnb98wdTbJ5VPOJKt44ONXfTwZueRV.e .sUuZTrDrYlsaIbf3NWY- Received: by 66.196.80.120; Sun, 17 Apr 2016 21:42:55 +0000 Date: Sun, 17 Apr 2016 21:42:52 +0000 (UTC) From: Jouni Laakso Reply-To: Jouni Laakso To: Adrian Chadd Cc: "freebsd-wireless@freebsd.org" Message-ID: <1081793933.2190222.1460929372233.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: Subject: Re: Huawei E3372 ( sonera.fi ) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Apr 2016 21:45:59 -0000 I'm happy someone answered and I'm not talking to myself. I finally had a question. 1) How to get two ways communication to succeed with this or these devices? Overall, how any IoT usb modem is connected with static IP-address? I have tried ipfw forward and tcpdump to snoop the traffic from ue0. I have put ipfw to forward all incoming packets to httpd-server. Both http and https. I can not see any traffic coming in from the modem 192.168.1.1. The forward rule is: ${fwcmd} add 100 fwd ${wwwip},80 tcp from any to 192.168.1.1 80 recv ${outif} ${fwcmd} add 100 fwd ${wwwip},443 tcp from any to 192.168.1.1 443 recv ${outif} This works with the proxy. This is not excactly NAT but no packets are found with ' tcpdump -n -i ue0 ' either. The modem has a www -admin page at http://192.168.1.1. I could not reach it's address from the Internet but sending to the public NAT address, finally the admin -page loaded to the web browser. Trying with google translate did not give results. Trying with another IP-connection did not reach the IP at all. 1.1) Should I enable PPP -link over the connection somehow? PPP was the connection method with the previous usb-modems and the IP at tun0 interface was given from the service provider. 2) Does anyone know how to switch the E3372 modem to a state giving a device to use the AT-commands? With these commands, listing the available modes is possible and solving the possibilities to use the modem revealed. Devices now are: crw------- 1 root operator 0xd1 Apr 17 21:26 pass3 crw-r----- 1 root operator 0xd2 Apr 17 21:26 da0 lrwxr-xr-x 1 root wheel 9 Apr 17 21:26 ugen4.2 -> usb/4.2.0 crw-rw-rw- 1 root wheel 0xc6 Apr 17 22:46 dsp0.0 crw------- 1 root wheel 0x4 Apr 18 00:07 console crw-rw-rw- 1 root wheel 0xd Apr 18 00:33 null 3) What is a correct IoT modem type? Is PPP ok with static IP-addresses or does it have to have NAT capabilities? Which ones have this? Answear to the question: Sorry my inaccuracy. It just seems to me that the latency is higher from just using the web browser. I have so many tests going on that I just haven't tested more accurately. Today I have been using the link first time with an antenna. The results would have been inaccurate. Personnally I think it can be either block sizes or differences in locking the cdce versus the u3g cuaU. Really I do not know. Maby these are the usual? Is it better to leave the modem to an external device or use it with the web browsers and applications? By the way, I'm using only 2 cores. This one uses less power. Maby it can affect the results?Maby it's just the antenna. E3372 has two antenna links. A polarized antenna or two antennas far apart could give better results. This is the configuration: 192.168.1.100 <--- cdce/usb ---> 192.168.1.1 <------ ISP 4G ------> It is not possible to add a NAT address to the Huawei modem because it does not have this kind of capability? At least not from the Admin-page. Or does it just send the packets destined to 192.168.1.1 to network 192.168.1.0 ? Tcpdump showed that nothing came back using the SSL-ports. With HTTP the public IP appeared many times until it was switched (maby with http redirect or similar?) back to the Admin page 192.168.1.1. The URL was first http://192.168.1.1/html/index.html?url= . Do I have to buy a new modem and what kind of a modem it should be? br, Jouni On Sunday, April 17, 2016 9:56 PM, Adrian Chadd wrote: > > >hi! this is cool to know! any ideas why the latency is higher? > > >-a > > > >On 16 April 2016 at 13:44, Jouni Laakso via freebsd-wireless > wrote: >> >> >> Hello list, >> >> >> I wanted to send this information to help others in their quest of 4G connectivity with FreeBSD here at Europes continent and in Finland. Huawei does not include a lot of information about their products. These 4G-network modems are usually provided by the subscriberline companies and with their own products. This one was from Sonera (Teliasonera, .se and .fi) here in Finland. >> Huawei E3372 seems to be a CDCE device. /boot/loader.conf has to have a line if_cdce_load="YES". Only usb_modeswitch works with this one. Command: >> /usr/local/sbin/usb_modeswitch --default-vendor 0x12d1 --default-product 0x1f01 -J >> swithes to the CDCE mode. Device ue0 appears to be configured (with ifconfig -command). Using 'dhclient ue0' a network address is found and using the address and adding a default router the network interface is usable. An admin HTTP-page can be found from http://192.168.1.1. CDCE has two network interfaces at both ends of USB. Both ends can be configured with their own IP-address. >> ID:s idVendor = 0x12d1 idProduct = 0x1f01 are switched to ID:s idVendor = 0x12d1 idProduct = 0x14dc . This seems to be correct since the connection to the Internet succeeded with cdce. >> Using u3g.c:U3G_DEV(HUAWEI, K3372_INIT, U3GINIT_HUAWEISCSI) >> Causes the modem to appear as a device id 0x1442 . Using this, only NTP port was listening. Maby this is a ntp mode. Using:U3G_DEV(HUAWEI, E3372_INIT, U3GINIT_HUAWEISCSI2) >> does not give any results. These are the current possibilities if compiling a new kernel every time is possible. >> It would be easier if a device had only one identification code. Reading about the different codes from usb_modeswitch list, it is maby clear that the service provider can change the device ID:s. This is not very easy to the users. If the device was only a modem, it would be usable without the flip-flop states of the modem-devices. ISO image is given with Windows and Linux drivers or software and after installing the software, the state becomes a modem state. Possibly with a HTTP-interface to connecto to the Internet. >> Quick test with Linux shows that the latency time is less with Linux. Previously using PPP with these kind of wireless devices, FreeBSD has shown best latency times. This is an estimate. Using an external modem (propably Linux inside) caused more latency with PPP over the previous 3G link. >> >> With best regards, >> >> Jouni L. >> _______________________________________________ >> freebsd-wireless@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless >> To unsubscribe, send any mail to "freebsd-wireless-unsubscribe@freebsd.org >" > > From owner-freebsd-wireless@freebsd.org Mon Apr 18 04:40:13 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9A5BCB111AD for ; Mon, 18 Apr 2016 04:40:13 +0000 (UTC) (envelope-from fnoyanisi@yahoo.com) Received: from nm2-vm5.bullet.mail.ne1.yahoo.com (nm2-vm5.bullet.mail.ne1.yahoo.com [98.138.91.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 682AC1C87 for ; Mon, 18 Apr 2016 04:40:12 +0000 (UTC) (envelope-from fnoyanisi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1460954230; bh=BrqF53jaIAnOylbK+X5cSiJq9SgkhvMBBm6mIX3Uqy0=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=FltEkIO+a4LP872PWysg1Is8m7KmuAIRRua7CQ2IClU3sosqO+sgHwASgebm6bq26CAraL6/V4/oy5cPBUuz02yTEO0Ea6Ttmm+8Hkdp/O2sSbZB86zSjkRcIY5KE6Ah20Wz56wNc6HykWGD4FurhfR/gV01qOfEK+UlguhwrQ6kecCHueJpEgFUojs+fYgQBNAgej5cDWbv/GnN+g0UVKboqjcNti5LVdDQeSLUGdLhifqgVzljPf9p9rAMxdlNRfh59Mcu3k/rMqEW8wFxl2fkV/Eit+Iw5UME+ypfmfvJgzE7gxQv01KZdc7m1PeeAtEKKPcsiT9wbSQHE3ow8w== Received: from [98.138.226.176] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 18 Apr 2016 04:37:10 -0000 Received: from [98.138.86.157] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 18 Apr 2016 04:37:10 -0000 Received: from [127.0.0.1] by omp1015.mail.ne1.yahoo.com with NNFMP; 18 Apr 2016 04:37:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 79266.44302.bm@omp1015.mail.ne1.yahoo.com X-YMail-OSG: oKVD.ToVM1lb8kpMzvzWnqiueAtCcy3iqNw1J_0EnZYkRL1B9sJmB66KZNemdi2 vmBR5hTvReNpmYrb0jTZDDoF0iqWsIu.Zg0GXOhcUPofqWZL.qXD6bPvwVVMPE6DYi9SJjtKDEGv gooGqXLiEAAv4.ENuH0fh5ksmRYNksnCITzj5GejBNvEcEvZVAjIeNM3N.x8pel8wFf1Cnfb.xcz B71Ar6UDxTEwZOc8vUAD5duMzYrGvoofVu29Que8QcRMFHk2yaXQzmDA0PIdh.fdR7tgWiBCr0Gn Gbuxh9UrYPRqH1Ma8g.sj3H2_Ew70goMKx50YR7geNVURL63uqahgZGJM9Nlnt3sByve7Rf7_12m _LieudBViMQS4LMSvxw7.0LUt1PKP4js9P_veYUC4YUADZ45s14IATYlG.afOTbq9XRun02oCtLb gR3aFAtKeSVFwLcelRSq.QmxubNbIPYxbNaC1h6o5eam56r7qD11_LbTkBU_LaXfPc0GVdmkXlW1 KYQeW26E- Received: by 98.138.105.216; Mon, 18 Apr 2016 04:37:09 +0000 Date: Mon, 18 Apr 2016 04:37:09 +0000 (UTC) From: Fehmi Noyan ISI Reply-To: Fehmi Noyan ISI To: "freebsd-wireless@freebsd.org" Message-ID: <1577375135.1864049.1460954229303.JavaMail.yahoo@mail.yahoo.com> Subject: struct ieee80211req_scan_result and couple of questions MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <1577375135.1864049.1460954229303.JavaMail.yahoo.ref@mail.yahoo.com> X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 04:40:13 -0000 Hi there, I have been digging into the IEEE 802.11 related code for a couple of days and need to clarify some points (or get my interpretation of the code confirmed :} ). So, here are some gray areas I have; 1 ) ioctl(2) returns a memory address (in i_data field of ireq structure) which points a series of "ieee80211req_scan_result" structures when request type is IEEE80211_IOC_SCAN_RESULTS, and it is the programmer's responsibility to parse the returned data in a proper way? The code for list_scan(int) in sbin/ifconfig/ifieee80211.c is a good example to this? 2 ) The "mesh" networking related parts of "ieee80211req_scan_result" structure are IEEE 802.11s additions? 3 ) A "ieee80211req_scan_result" structure can either have an SSID or a MESH ID? If so, in the code snippet below (from sbin/ifconfig/ifieee80211.c) /* cp points a memory location returned by ioctl(2) * when request = IEEE80211_IOC_SCAN_RESULTS */ const uint8_t *vp, *idp; sr = (const struct ieee80211req_scan_result *) cp; vp = cp + sr->isr_ie_off; if (sr->isr_meshid_len) { idp = vp + sr->isr_ssid_len; idlen = sr->isr_meshid_len; } else { idp = vp; idlen = sr->isr_ssid_len; } why don't we have if (sr->isr_meshid_len) { idp = vp + sr->isr_meshid_len; /* THIS LINE */ idlen = sr->isr_meshid_len; } else { idp = vp; idlen = sr->isr_ssid_len; } Assuming the memory is organized like this +-------------------+----+------+---------+ | Fixed Size struct | IE | SSID | MESH ID | +-------------------+----+------+---------+ 4 ) NET80211(4) manual page does not include the description of ieee80211req_scan_result structure. Would be good to have in the manual page rather than reading the net80211/ieee80211_ioctl.h file. I am happy to submit a patch if you aggree that a definition of ieee80211req_scan_result should appear in net80211(4). This will be freebsd-doc related issue then. Regards Fehmi From owner-freebsd-wireless@freebsd.org Tue Apr 19 12:41:33 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FCDDB14ED8 for ; Tue, 19 Apr 2016 12:41:33 +0000 (UTC) (envelope-from jounijl@yahoo.co.uk) Received: from nm42-vm0.bullet.mail.ne1.yahoo.com (nm42-vm0.bullet.mail.ne1.yahoo.com [98.138.121.56]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D07141528 for ; Tue, 19 Apr 2016 12:41:32 +0000 (UTC) (envelope-from jounijl@yahoo.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1461069686; bh=1AHc1gLyi5jrTUVs6+NmlOG0XUqqcTB6kHH/Dvyx6Cc=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=BDFXK++ILPFra7v5VQO6tLg4hSkQWlgAE3vaEtOLmIrrwd3bpA0KQ87xpGXzuw+uG7gBw4KYg3Xwyp+XRSIXEl+YhCugtvjgzsi2xTEFAHYmXBhbi1CBhii4mM5Ioq1opJnrb4Ooq8PlMobWCHGEsEM3gumhXsB316r6IbAwdDRumDl1SyNWoXfBMQ2EEC6SeCCYNbZR2qJHsz9JoMQrBbLvo9lwoby3WehldQ5bHk5LYJMbsiSfcSV05cAGtmPabrt7XJiR3bdEh7Fk4rx8xPx7acSQjFOZ/aWqj/euNrvaMPNI3RKfddlfKMQ6IvrpOcHc/4sWjtFfceY2NGV87Q== Received: from [127.0.0.1] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 19 Apr 2016 12:41:26 -0000 Received: from [98.138.101.132] by nm42.bullet.mail.ne1.yahoo.com with NNFMP; 19 Apr 2016 12:38:35 -0000 Received: from [98.139.170.179] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 19 Apr 2016 12:38:35 -0000 Received: from [98.139.212.245] by tm22.bullet.mail.bf1.yahoo.com with NNFMP; 19 Apr 2016 12:38:35 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 19 Apr 2016 12:38:35 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 420050.54238.bm@omp1054.mail.bf1.yahoo.com X-YMail-OSG: ppOhOiIVM1neeUkM7mkjeWo7DDjiJk866VxGFwJn6HoE9xWvZZceqBd9kIp6iRz Q2UbjAwKXmxI1i7CTIdcWhMlHHpyOCGuOBHHS5ayYIsAzHPF3RoAJZXRjJ4lOyEd6mzPwt1QSe7G w.NZGUsmN2INzvUsPKOx9xQ3pawB1ooyWgTEo1we9m6WR.mmi6CyFE8o_1CF7kOcdxOTkwxvwzIe eyb3o4HC7viPDIvt_taKs9z5iSBK2cfW45d382AX2oHA7DFvYodT8dDCQ_kZH.N4GrASVtpd7eVA zHLbOcv1_Wo1zBQ.3Vq1jcGofZdS_acnrWtkgBwjSn6ROyYVj6O41Ai0dIb0SAzS.z.u2BLSur0W 9p1bD6GH5E_hyMIUDHB2s1WVvcHBDbXwvVmlp8mNJ3V9_lDuvuDBQfsSAptlVQeGiM.XcW2WeqCq IYPM8ZRSYLC0tFjjZgCn8b7BAquEkCKqFhLLC1AIR.SOOG1L8mxisOPvL62ELlY5W.pIu_4Ks9Ln TPZ6MHVFiKTrulvSuZwnRnU7K Received: by 66.196.81.108; Tue, 19 Apr 2016 12:38:34 +0000 Date: Tue, 19 Apr 2016 12:38:32 +0000 (UTC) From: Jouni Laakso Reply-To: Jouni Laakso To: "freebsd-wireless@freebsd.org" Message-ID: <910916415.3235415.1461069512944.JavaMail.yahoo@mail.yahoo.com> Subject: Re: Huawei E3372 ( sonera.fi ) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit References: <910916415.3235415.1461069512944.JavaMail.yahoo.ref@mail.yahoo.com> X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 12:41:33 -0000 And the solution. The short www-page is loaded from 4G FreeBSD server in (latency is missing here): Europe: 153 ms USA: 406 ms Asia/Pacific: 757 ms Commands: # # Adding the needed packages: # [root]# pkg install miniupnpc # # Switching the E3372 to to cdce # [root]# /usr/local/sbin/usb_modeswitch --default-vendor 0x12d1 --default-product 0x1f01 -J # # Adding ip-address and default route # [root]# dhclient ue0 # First time with dhclient [root]# ifconfig ue0 ... # Next time with static IP settings [root]# /sbin/route add default # # Adding a NAT -address to the Huawei E3372: # [root]# upnpc -t 10 -m ue0 -a 80 80 tcp [root]# upnpc -t 10 -m ue0 -a 443 443 tcp # # Listing the NAT -addresses # [root]# upnpc -t 10 -m ue0 -l # # And the ISP may have different APN for the static IP service. Configured from: # URL: http:// # uPnP does the trick. Firewall has to have 1900/udp open including multicast IP from the server to the modem. wkr, Jouni > On Tuesday, April 19, 2016 11:48 AM, Jouni Laakso wrote: >> On Monday, April 18, 2016 12:42 AM, Jouni Laakso wrote: 192.168.1.100 <--- cdce/usb ---> 192.168.1.1 <--- ISP 4G ---> >> On Sunday, April 17, 2016 9:56 PM, Adrian Chadd >>> On 16 April 2016 at 13:44, Jouni Laakso via freebsd-wireless From owner-freebsd-wireless@freebsd.org Tue Apr 19 20:20:17 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 911FBB14673 for ; Tue, 19 Apr 2016 20:20:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 81B71167B for ; Tue, 19 Apr 2016 20:20:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u3JKKH50020138 for ; Tue, 19 Apr 2016 20:20:17 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 208605] Kernel panic when unplug and replug USB WiFi dongle. Date: Tue, 19 Apr 2016 20:20:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2016 20:20:17 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208605 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: avos Date: Tue Apr 19 20:19:22 UTC 2016 New revision: 298293 URL: https://svnweb.freebsd.org/changeset/base/298293 Log: net80211: do not reschedule scan_curchan_task() if the scan was canceled. This should fix possible use-after-free in the scheduled task. PR: 208605 Changes: head/sys/net80211/ieee80211_scan_sw.c --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-wireless@freebsd.org Wed Apr 20 13:44:51 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9DE0B159E6 for ; Wed, 20 Apr 2016 13:44:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA62E1149 for ; Wed, 20 Apr 2016 13:44:51 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u3KDipdv036590 for ; Wed, 20 Apr 2016 13:44:51 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 208933] [regression] "ifconfig wlan0 ether ..." broken after r297592 Date: Wed, 20 Apr 2016 13:44:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fk@fabiankeil.de X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter cc Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2016 13:44:51 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208933 Bug ID: 208933 Summary: [regression] "ifconfig wlan0 ether ..." broken after r297592 Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Keywords: regression Severity: Affects Some People Priority: --- Component: wireless Assignee: freebsd-wireless@FreeBSD.org Reporter: fk@fabiankeil.de CC: avos@freebsd.org Keywords: regression After r297592, wpa_supplicant can no longer associate to an AP if wlan0's MAC address has been changed with "ifconfig wlan0 ether ...": wpa_supplicant[76190]: wlan0: Trying to associate with [...] (SSID=3D'[...]' freq=3D2447 MHz) wpa_supplicant[76190]: wlan0: Authentication with [...] timed out. wpa_supplicant[76190]: wlan0: CTRL-EVENT-DISCONNECTED bssid=3D[...]reason= =3D3 locally_generated=3D1 After destroying the device and recreating it without changing the MAC address afterwards, wpa_supplicant can associate with the AP again. In my case the wlandev is iwn0, but looking at r297592 I suspect that this is not a device-specific issue. Reverting r297592 works around the problem. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-wireless@freebsd.org Thu Apr 21 08:33:20 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4A34B153E9 for ; Thu, 21 Apr 2016 08:33:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9506318F0 for ; Thu, 21 Apr 2016 08:33:20 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u3L8XKrI023776 for ; Thu, 21 Apr 2016 08:33:20 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 169199] [ath] Cannot set up static ip addresses for wireless with wpa encryption Date: Thu, 21 Apr 2016 08:33:20 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: avos@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-wireless@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:33:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D169199 Andriy Voskoboinyk changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |avos@freebsd.org --- Comment #5 from Andriy Voskoboinyk --- +1 (RTL8188CUS, i386-20160408-r297692-bootonly snapshot); as I can see in ttyv2, it fails with: DEBUG: dialog.subr: DIALOG_SELF_INITIALIZE=3D[1] DEBUG: f_dialog_init: ARGV=3D[wlan0 WPA ] GETOPTS_STDARGS=3D[dD:SX] DEBUG: f_dialog_init: SECURE=3D[] USE_XDIALOG=3D[] DEBUG: f_dialog_init: dialog(1) API initialized. DEBUG: dialog.subr: Successfully loaded. ifconfig: WPA: bad value route: route has not been found route: writing to routing socket: Network is unreachable ifconfig: create: bad value (looks like it tries to pass WPA as an argument to ifconfig(8)). --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-wireless@freebsd.org Thu Apr 21 08:42:10 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8459DB15796 for ; Thu, 21 Apr 2016 08:42:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 74B3E1CE2 for ; Thu, 21 Apr 2016 08:42:10 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u3L8gAA0043559 for ; Thu, 21 Apr 2016 08:42:10 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-wireless@FreeBSD.org Subject: [Bug 169199] [ath] Cannot set up static ip addresses for wireless with wpa encryption Date: Thu, 21 Apr 2016 08:42:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: wireless X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: avos@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-sysinstall@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_severity assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2016 08:42:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D169199 Andriy Voskoboinyk changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Affects Only Me |Affects Some People Assignee|freebsd-wireless@FreeBSD.or |freebsd-sysinstall@FreeBSD. |g |org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-wireless@freebsd.org Fri Apr 22 07:11:21 2016 Return-Path: Delivered-To: freebsd-wireless@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9A3DB18005 for ; Fri, 22 Apr 2016 07:11:21 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msa02b.plala.or.jp (msa02.plala.or.jp [58.93.240.2]) by mx1.freebsd.org (Postfix) with ESMTP id 6127A11C3 for ; Fri, 22 Apr 2016 07:11:20 +0000 (UTC) (envelope-from ish@amail.plala.or.jp) Received: from msc01.plala.or.jp ([172.23.12.31]) by msa02b.plala.or.jp with ESMTP id <20160422071112.NAWW4431.msa02b.plala.or.jp@msc01.plala.or.jp> for ; Fri, 22 Apr 2016 16:11:12 +0900 Received: from localhost ([121.117.64.178]) by msc01.plala.or.jp with ESMTP id <20160422071112.SEHR29353.msc01.plala.or.jp@localhost> for ; Fri, 22 Apr 2016 16:11:12 +0900 Date: Fri, 22 Apr 2016 16:10:46 +0900 (JST) Message-Id: <20160422.161046.1399384989198011599.ish@amail.plala.or.jp> To: freebsd-wireless@freebsd.org Subject: Re: iwm7265fw: fatal firmware error From: Masachika ISHIZUKA In-Reply-To: <20160305.193602.2144207354689575871.ish@amail.plala.or.jp> References: <6E0E9EC8-3035-4443-A495-5981E8C9D4FA@FreeBSD.org> <20160305.193602.2144207354689575871.ish@amail.plala.or.jp> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Apr_22_16_10_46_2016_896)--" Content-Transfer-Encoding: 7bit X-VirusScan: Outbound; msa02m; Fri, 22 Apr 2016 16:11:12 +0900 X-BeenThere: freebsd-wireless@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Discussions of 802.11 stack, tools device driver development." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Apr 2016 07:11:22 -0000 ----Next_Part(Fri_Apr_22_16_10_46_2016_896)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit >> May be workaroundable with https://reviews.freebsd.org/D4236 (restarts >> the device >> automatically after each failure; but the problem is still here) > > Hello, Andriy. > > Thank you for good information. > After applying this patch, my dell notebook with 7260 can restart > iwm driver automatically and resume connections. Hi. As my dell xps12 (7260ac) was disconnected after key renewal interval time, I patched iwm driver. After that, it keeps connctions. # cd /sys/dev/iwm # patch < iwm.diff # cd /sys/module/iwm # make # make install # reboot -- Masachika ISHIZUKA ----Next_Part(Fri_Apr_22_16_10_46_2016_896)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="iwm.diff" --- /sys/dev/iwm/if_iwm.c.org 2016-02-01 15:01:34.003243000 +0900 +++ /sys/dev/iwm/if_iwm.c 2016-04-21 14:24:02.691305000 +0900 @@ -3159,7 +3159,6 @@ struct iwm_node *in; struct iwm_vap *iv = IWM_VAP(vap); uint32_t duration; - uint32_t min_duration; int error; /* @@ -3201,7 +3200,25 @@ if (iv->is_uploaded) { if ((error = iwm_mvm_mac_ctxt_changed(sc, vap)) != 0) { device_printf(sc->sc_dev, - "%s: failed to add MAC\n", __func__); + "%s: failed to update MAC\n", __func__); + goto out; + } + if ((error = iwm_mvm_phy_ctxt_changed(sc, &sc->sc_phyctxt[0], + in->in_ni.ni_chan, 1, 1)) != 0) { + device_printf(sc->sc_dev, + "%s: failed update phy ctxt\n", __func__); + goto out; + } + in->in_phyctxt = &sc->sc_phyctxt[0]; + + if ((error = iwm_mvm_binding_update(sc, in)) != 0) { + device_printf(sc->sc_dev, + "%s: binding update cmd\n", __func__); + goto out; + } + if ((error = iwm_mvm_update_sta(sc, in)) != 0) { + device_printf(sc->sc_dev, + "%s: failed to update sta\n", __func__); goto out; } } else { @@ -3210,61 +3227,35 @@ "%s: failed to add MAC\n", __func__); goto out; } - } - - if ((error = iwm_mvm_phy_ctxt_changed(sc, &sc->sc_phyctxt[0], - in->in_ni.ni_chan, 1, 1)) != 0) { - device_printf(sc->sc_dev, - "%s: failed add phy ctxt\n", __func__); - goto out; - } - in->in_phyctxt = &sc->sc_phyctxt[0]; - - if ((error = iwm_mvm_binding_add_vif(sc, in)) != 0) { - device_printf(sc->sc_dev, - "%s: binding cmd\n", __func__); - goto out; - } - - if ((error = iwm_mvm_add_sta(sc, in)) != 0) { - device_printf(sc->sc_dev, - "%s: failed to add MAC\n", __func__); - goto out; - } - - /* a bit superfluous? */ - while (sc->sc_auth_prot) - msleep(&sc->sc_auth_prot, &sc->sc_mtx, 0, "iwmauth", 0); - sc->sc_auth_prot = 1; - - duration = min(IWM_MVM_TE_SESSION_PROTECTION_MAX_TIME_MS, - 200 + in->in_ni.ni_intval); - min_duration = min(IWM_MVM_TE_SESSION_PROTECTION_MIN_TIME_MS, - 100 + in->in_ni.ni_intval); - iwm_mvm_protect_session(sc, in, duration, min_duration, 500); - - IWM_DPRINTF(sc, IWM_DEBUG_RESET, - "%s: waiting for auth_prot\n", __func__); - while (sc->sc_auth_prot != 2) { - /* - * well, meh, but if the kernel is sleeping for half a - * second, we have bigger problems - */ - if (sc->sc_auth_prot == 0) { + if ((error = iwm_mvm_phy_ctxt_changed(sc, &sc->sc_phyctxt[0], + in->in_ni.ni_chan, 1, 1)) != 0) { device_printf(sc->sc_dev, - "%s: missed auth window!\n", __func__); - error = ETIMEDOUT; + "%s: failed add phy ctxt\n", __func__); goto out; - } else if (sc->sc_auth_prot == -1) { + } + in->in_phyctxt = &sc->sc_phyctxt[0]; + + if ((error = iwm_mvm_binding_add_vif(sc, in)) != 0) { + device_printf(sc->sc_dev, + "%s: binding add cmd\n", __func__); + goto out; + } + if ((error = iwm_mvm_add_sta(sc, in)) != 0) { device_printf(sc->sc_dev, - "%s: no time event, denied!\n", __func__); - sc->sc_auth_prot = 0; - error = EAUTH; + "%s: failed to add sta\n", __func__); goto out; } - msleep(&sc->sc_auth_prot, &sc->sc_mtx, 0, "iwmau2", 0); } - IWM_DPRINTF(sc, IWM_DEBUG_RESET, "<-%s\n", __func__); + + /* + * Prevent the FW from wandering off channel during association + * by "protecting" the session with a time event. + */ + /* XXX duration is in units of TU, not MS */ + duration = IWM_MVM_TE_SESSION_PROTECTION_MAX_TIME_MS; + iwm_mvm_protect_session(sc, in, duration, 500 /* XXX magic number */); + DELAY(100); + error = 0; out: ieee80211_free_node(ni); --- /sys/dev/iwm/if_iwm_binding.c.org 2015-10-23 16:11:37.635797000 +0900 +++ /sys/dev/iwm/if_iwm_binding.c 2016-04-20 15:17:32.934703000 +0900 @@ -201,13 +201,13 @@ } int -iwm_mvm_binding_update(struct iwm_softc *sc, struct iwm_node *in, int add) +iwm_mvm_binding_update(struct iwm_softc *sc, struct iwm_node *in) { - return iwm_mvm_binding_cmd(sc, in, IWM_FW_CTXT_ACTION_ADD); + return iwm_mvm_binding_cmd(sc, in, IWM_FW_CTXT_ACTION_MODIFY); } int iwm_mvm_binding_add_vif(struct iwm_softc *sc, struct iwm_node *in) { - return iwm_mvm_binding_update(sc, in, IWM_FW_CTXT_ACTION_ADD); + return iwm_mvm_binding_cmd(sc, in, IWM_FW_CTXT_ACTION_ADD); } --- if_iwm_binding.h.org 2015-10-23 16:11:31.950989000 +0900 +++ if_iwm_binding.h 2016-04-21 14:29:44.352627000 +0900 @@ -107,8 +107,7 @@ extern int iwm_mvm_binding_cmd(struct iwm_softc *sc, struct iwm_node *in, uint32_t action); -extern int iwm_mvm_binding_update(struct iwm_softc *sc, struct iwm_node *in, - int add); +extern int iwm_mvm_binding_update(struct iwm_softc *sc, struct iwm_node *in); extern int iwm_mvm_binding_add_vif(struct iwm_softc *sc, struct iwm_node *in); #endif /* __IF_IWM_BINDING_H__ */ --- if_iwm_time_event.c.org 2015-10-23 16:11:37.636104000 +0900 +++ if_iwm_time_event.c 2016-04-21 14:26:11.776447000 +0900 @@ -244,7 +244,7 @@ void iwm_mvm_protect_session(struct iwm_softc *sc, struct iwm_node *in, - uint32_t duration, uint32_t min_duration, uint32_t max_delay) + uint32_t duration, uint32_t max_delay) { struct iwm_time_event_cmd_v2 time_cmd; --- /sys/dev/iwm/if_iwm_time_event.h.org 2015-10-23 16:11:35.320341000 +0900 +++ /sys/dev/iwm/if_iwm_time_event.h 2016-04-21 14:26:54.507584000 +0900 @@ -108,6 +108,6 @@ #define __IF_IWM_TIME_EVENT_H__ extern void iwm_mvm_protect_session(struct iwm_softc *sc, struct iwm_node *in, - uint32_t duration, uint32_t min_duration, uint32_t max_delay); + uint32_t duration, uint32_t max_delay); #endif /* __IF_IWM_TIME_EVENT_H__ */ ----Next_Part(Fri_Apr_22_16_10_46_2016_896)----