TRADING ACCOUNT

[KELLY ALAN]

Dear sir ,

I KELLY ALAN  purchasing and sales manager of CFM INTERNATIONAL .Our 
Company specialised in Supplying computer hardware and Electronic .We 
want to extend our supplier list because of concurrency in prices on the 
international market. We are seeking a supplier with whom we can to have 
 partnered long-term in order to have competitive prices . we are 
interested to buy the products you sell and want to place an order with 
you in big quantities.
Can you give us payment facilities ( 14 , 30 or 60 days payment terms ) 
?
What is the procedure for our account opening  and credit line 
application ?


Cordially

 KELLY ALAN

CFM INTERNATIONAL
2 BOULEVARD DU GAL MARTIAL VALIN
75015 PARIS
REG N° 302 527 700
VAT N° FR90 302527700
TEL +33171025367
FAX +33177759149
https://www.cfmaeroengines.com

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

[Alan Cox]

On Mon, 8 Jan 2018 11:08:36 +0100
Peter Zijlstra <pet...@infradead.org> wrote:

> On Fri, Jan 05, 2018 at 10:30:16PM -0800, Dan Williams wrote:
> > On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman <ebied...@xmission.com> 
> > wrote:  
> > > In at least one place (mpls) you are patching a fast path.  Compile out
> > > or don't load mpls by all means.  But it is not acceptable to change the
> > > fast path without even considering performance.  
> > 
> > Performance matters greatly, but I need help to identify a workload
> > that is representative for this fast path to see what, if any, impact
> > is incurred. Even better is a review that says "nope, 'index' is not
> > subject to arbitrary userspace control at this point, drop the patch."  
> 
> I think we're focussing a little too much on pure userspace. That is, we
> should be saying under the attackers control. Inbound network packets
> could equally be under the attackers control.

Inbound network packets don't come with a facility to read back and do
cache timimg. For the more general case, timing attacks on network
activity are not exactly new, and you have to mitigate them in user space
because most of them are about how many instructions you execute on each
path. The ancient classic being telling if a user exists by seeing if the
password was actually checked.

Alan

Re: [PATCH 08/18] carl9170: prevent bounds-check bypass via speculative execution

[Alan Cox]

> The only way a user can set this in any meaningful way would be via
> a NL80211_CMD_SET_WIPHY netlink message. However, the value will get
> vetted there by cfg80211's parse_txq_params [0]. This is long before

Far more than a couple of hundred instructions ? The problem is that the
processor will speculate that the parameter is valid and continue on that
basis until the speculation resolves or it hits some other limit that
stops it speculating further. That can be quite a distance on a modern
x86 processor, and for all we know could be even more on some of the
other CPUs involved.

> it reaches any of the *_op_conf_tx functions.
> 
> And Furthermore a invalid queue (param->ac) would cause a crash in 
> this line in mac80211 before it even reaches the driver [1]:
> | sdata->tx_conf[params->ac] = p;
> |   

Firstly it might not because the address you get as a result could be
valid kernel memory. In fact your attackers wants it to be valid kernel
memory since they are trying to find the value of a piece of that memory.

Secondly the processor is doing this speculatively so it won't fault. It
will eventually decide it went the wrong way and throw all the
speculative work away - leaving footprints. It won't fault unless the
speculative resolves that was the real path the code took.

If it's not a performance critical path then it's better to be safe.

Alan

[PATCH] ath6k1: add Dell OEM SDIO I/O for the Venue 8 Pro

[Alan]

From: Adam Williamson <ad...@happyassassin.net>

SDIO ID 0271:0418

Signed-off-by: Alan Cox <a...@linux.intel.com>
Bugzilla-ID: https://bugzilla.kernel.org/show_bug.cgi?id=67921

diff --git a/drivers/net/wireless/ath/ath6kl/sdio.c 
b/drivers/net/wireless/ath/ath6kl/sdio.c
index eab0ab9..76eb336 100644
--- a/drivers/net/wireless/ath/ath6kl/sdio.c
+++ b/drivers/net/wireless/ath/ath6kl/sdio.c
@@ -1401,6 +1401,7 @@ static const struct sdio_device_id ath6kl_sdio_devices[] 
= {
{SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x0))},
{SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x1))},
{SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x2))},
+   {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x18))},
{},
 };
 

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[Alan Curry]

Christian Lamparter wrote:
> 
> One thing I noticed in your previous post is that you "might" not have
> draft-802.11n enabled. Do you see any "disabling HT/VHT due to WEP/TKIP use."
> in your dmesg logs? If so, check if you can force your AP to use WPA2
> with CCMP/AES only.
> 

Yes, I've had that message. The reason wan't on the AP though. My
wpa_supplicant.conf only had TKIP enabled, because that's what was in the
sample configuration file I started with. Adding CCMP there worked, and in
that mode I'm no longer getting any corrupted packets.

If I'd paid attention to the encryption options when setting up this network
originally, I would have had CCMP the whole time, with no corrupted packets,
and never would have found the iov iterator bug...

-- 
Alan Curry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[Alan Curry]

Al Viro wrote:
> 
> Which just might mean that we have *three* issues here -
>   (1) buggered __copy_to_user_inatomic() (and friends) on some sparcs
>   (2) your ssl-only corruption
>   (3) Alan's x86_64 corruption on plain TCP read - no ssl *or* sparc
> anywhere, and no multi-segment recvmsg().  Which would strongly argue in
> favour of some kind of copy_page_to_iter() breakage triggered when handling
> a fragmented skb, as in (1).  Except that I don't see anything similar in
> x86_64 uaccess primitives...
> 

I think I've solved (3) at least...

Using the twin weapons of printk and stubbornness, I have built a working
theory of the bug. I haven't traced it all the way through, so my explanation
may be partly wrong. I do have a patch that eliminates the symptom in all my
tests though. Here's what happens:

A corrupted packet somehow arrives in skb_copy_and_csum_datagram_msg().
During downloads at reasonably high speed, about 0.1% of my incoming
packets are bad. Probably because the access point is that suspicious
Comcast thing.

skb_copy_and_csum_datagram_msg() does this:

if (skb_copy_and_csum_datagram(skb, hlen, >msg_iter,
   chunk, ))
goto fault;
if (csum_fold(csum))
goto csum_error;

skb_copy_and_csum_datagram() copies the bad data, computes the checksum,
and *advances the iterator*. The checksum is bad, so it goes to
csum_error, which returns without indicating success to userspace, but the
bad data is in the userspace buffer, and since the iterator has advanced,
the proper data doesn't get written to the proper place when it arrives in a
retransmission. The same iterator is still used because we're still in the
same syscall (I guess - this is one of the parts I didn't check out).

My ugly patch fixes this in the most obvious way: make a local copy of
msg->msg_iter before the call to skb_copy_and_csum_datagram(), and copy it
back if the checksum is bad, just before "goto csum_error;". (I wonder if the
other failure exits from this function might need to do the same thing.)

You can probably reproduce this problem if you deliberately inject some
bad TCP checksums into a stream. Just make sure the receiving machine is
in a blocking read() on the socket when the bad packet arrives. You may
need to resend the offending packet afterward with the checksum corrected.

diff --git a/net/core/datagram.c b/net/core/datagram.c
index b7de71f..574d4bf 100644
--- a/net/core/datagram.c
+++ b/net/core/datagram.c
@@ -730,6 +730,7 @@ int skb_copy_and_csum_datagram_msg(struct sk_buff *skb,
 {
__wsum csum;
int chunk = skb->len - hlen;
+   struct iov_iter save_iter;
 
if (!chunk)
return 0;
@@ -741,11 +742,14 @@ int skb_copy_and_csum_datagram_msg(struct sk_buff *skb,
goto fault;
} else {
csum = csum_partial(skb->data, hlen, skb->csum);
+   memcpy(_iter, >msg_iter, sizeof save_iter);
if (skb_copy_and_csum_datagram(skb, hlen, >msg_iter,
   chunk, ))
goto fault;
-   if (csum_fold(csum))
+   if (csum_fold(csum)) {
+   memcpy(>msg_iter, _iter, sizeof save_iter);
goto csum_error;
+   }
if (unlikely(skb->ip_summed == CHECKSUM_COMPLETE))
netdev_rx_csum_fault(skb->dev);
}

-- 
Alan Curry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[Alan Curry]

Al Viro wrote:
> 
> Another thing (and if that works, it's *NOT* a proper fix - it would be
> papering over the problem, but at least it would show where to look for
> it) - try (on top of mainline) the following delta:

I tried it on top of v4.6.4 and on top of the very recent v4.7-2509-g59ebc44
from Linus, and still got corruption.

> 
> diff --git a/net/core/datagram.c b/net/core/datagram.c
> index b7de71f..0ee5995 100644
> --- a/net/core/datagram.c
> +++ b/net/core/datagram.c
> @@ -734,7 +734,7 @@ int skb_copy_and_csum_datagram_msg(struct sk_buff *skb,
>   if (!chunk)
>   return 0;
>  
> - if (msg_data_left(msg) < chunk) {
> + if (iov_iter_single_seg_count(>msg_iter) < chunk) {
>   if (__skb_checksum_complete(skb))
>   goto csum_error;
>   if (skb_copy_datagram_msg(skb, hlen, msg, chunk))
> 

-- 
Alan Curry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[Alan Curry]

Christian Lamparter wrote:
> Thanks, I gave the program a try with my WNDA3100 and a WN821N v2 devices.
> I did not see any corruptions in any of the tests though. Can you tell me
> something about your wireless network too? I would like to know what router
> and firmware are you using? Also important: what's your wireless 
> configuration?

The router/access-point is a Comcast-issued Technicolor cable modem, model
TC8305C. The only thing I can find on it that looks like it might identify
a firmware version is this:

System Software Version

eMTA & DOCSIS Software Version: 01.E6.01.22.25
Packet Cable: 2.0

I assume Comcast pushes firmware updates whenever they feel like it.

There is possibly another clue. I get this message from the kernel sometimes:

ieee80211 phy0: invalid plcp cck rate (0).

I had this message appearing long before the data corruption bug started.
It never correlated with any actual problems, so I turned down the priority
level of the message to get it off the console, and forgot about it. I
was unable to discover what a "plcp" or "cck" is so the message means
nothing to me.

> (WPA?, CCMP or TKIP? HT40, HT20 or Legacy rates? ...)
> 
> Probably the quickest and easiest way to get that information is by running
> the following commands as root, when you are connected to your wifi network
> and post the results:
> # iw dev wlan0 link
> # iw dev wlan0 scan dump

Connected to cc:03:fa:bf:e9:ea (on wlan0)
SSID: HOME-E9EA
freq: 2462
RX: 20726719 bytes (106483 packets)
TX: 5902478 bytes (44707 packets)
signal: -43 dBm
tx bitrate: 54.0 MBit/s

bss flags:  short-slot-time
dtim period:1
beacon int: 100

BSS cc:03:fa:bf:e9:ea(on wlan0) -- associated
TSF: 236407205748 usec (2d, 17:40:07)
freq: 2462
beacon interval: 100 TUs
capability: ESS Privacy ShortSlotTime (0x0411)
signal: -33.00 dBm
last seen: 634452 ms ago
Information elements from Probe Response frame:
SSID: HOME-E9EA
Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0* 36.0 54.0 
DS Parameter set: channel 11
ERP: 
ERP D4.0: 
RSN: * Version: 1
 * Group cipher: TKIP
 * Pairwise ciphers: CCMP TKIP
 * Authentication suites: PSK
 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
Extended supported rates: 6.0* 9.0 12.0* 48.0 
HT capabilities:
Capabilities: 0x18bd
RX LDPC
HT20
SM Power Save disabled
RX Greenfield
RX HT20 SGI
TX STBC
No RX STBC
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT RX MCS rate indexes supported: 0-23
HT TX MCS rate indexes are undefined
HT operation:
 * primary channel: 11
 * secondary channel offset: no secondary
 * STA channel width: 20 MHz
 * RIFS: 1
 * HT protection: nonmember
 * non-GF present: 1
 * OBSS non-GF present: 1
 * dual beacon: 0
 * dual CTS protection: 0
 * STBC beacon: 0
 * L-SIG TXOP Prot: 0
 * PCO active: 0
 * PCO phase: 0
WPS: * Version: 1.0
 * Wi-Fi Protected Setup State: 2 (Configured)
 * Response Type: 3 (AP)
 * UUID: 6d1b1911-14a9-391c-cdee-89850a5aa1ef
 * Manufacturer: Technicolor
 * Model: Technicolor
 * Model Number: 123456
 * Serial Number: 001
 * Primary Device Type: 6-0050f204-1
 * Device name: TechnicolorAP
 * Config methods: Display
 * RF Bands: 0x1
 * Unknown TLV (0x1049, 6 bytes): 00 37 2a 00 01 20
WPA: * Version: 1
 * Group cipher: TKIP
 * Pairwise ciphers: CCMP TKIP
 * Authentication suites: PSK
 * Capabilities: 16-PTKSA-RC 1-GTKSA-RC (0x000c)
WMM: * Parameter version 1
 * u-APSD
 * BE: CW 15-1023, AIFSN 3
 * BK: CW 15-1023, AIFSN 7
 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
 * VO: CW 3-7, AIFSN 2, TXOP 1504 usec

-- 
Alan Curry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[Alan Curry]

Al Viro wrote:
> On Sun, Jul 24, 2016 at 07:45:13PM +0200, Christian Lamparter wrote:
> 
> > > The symptom is that downloaded files (http, ftp, and probably other
> > > protocols) have small corrupted segments (about 1-2 kilobytes long) in
> > > random locations. Only downloads that sustain a high speed for at least a
> > > few seconds are corrupted. Anything small enough to be received in less
> > > than about 5 seconds is not affected.
> 
> Can that sucker be reproduced with netcat?  That would eliminate all issues
> with multi-iovec recvmsg(2), narrowing the things down quite bit.

netcat seems to be immune. Comparing strace results, I didn't see any
recvmsg() calls in the other programs that have had the problem, but there
is an interesting difference: netcat calls select() to wait for the socket
to be ready for reading, where my other test programs just call read() and
let it block until ready.

So I wrote a small test program to isolate that difference. It downloads
a file using only read() and write() and a hardcoded HTTP request. It has
a select mode (main loop alternates read() and select() on the TCP socket)
and a noselect mode (main loop just read()s the TCP socket).

The program is included at the bottom of this message.

I ran it several times in both modes and got corruption if and only if the
noselect mode was used.

> 
> Another thing (and if that works, it's *NOT* a proper fix - it would be
> papering over the problem, but at least it would show where to look for
> it) - try (on top of mainline) the following delta:
> 
> diff --git a/net/core/datagram.c b/net/core/datagram.c

Will try that patch soon. Meanwhile, here's my test:

/* Demonstration program "dlbug".
   Usage: dlbug select > outfile
  or
  dlbug noselect > outfile
   outfile will contain the full HTTP response. Edit out the HTTP headers
   and what's left should be a valid gzip if the download worked. */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
  const char *request =
"GET /debian/dists/stable/main/Contents-amd64.gz HTTP/1.0\r\n"
"Host: ftp.us.debian.org\r\n"
"\r\n";
  ssize_t request_len = strlen(request), w, r, copied;
  struct addrinfo hints, *host;
  int sock, err, doselect;
  char buf[10240];

  if(argc!=2 || (!strcmp(argv[1], "select") && !strcmp(argv[1], "noselect"))) {
fprintf(stderr, "Usage: %s {select|noselect}\n", argv[0]);
return 1;
  }

  doselect = !strcmp(argv[1], "select");

  memset(, 0, sizeof hints);
  hints.ai_family = AF_INET;
  hints.ai_socktype = SOCK_STREAM;

  err = getaddrinfo("ftp.us.debian.org", 0, , );
  if(err) {
fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(err));
return 1;
  }

  sock = socket(host->ai_family, host->ai_socktype, host->ai_protocol);
  if(sock < 0) {
perror("socket");
return 1;
  }

  ((struct sockaddr_in *)host->ai_addr)->sin_port = htons(80);

  if(connect(sock, host->ai_addr, host->ai_addrlen) < 0) {
perror("connect");
return 1;
  }

  while(request_len) {
w = write(sock, request, request_len);
if(w < 0) {
  perror("write to socket");
  return 1;
}
request += w;
request_len -= w;
  }

  while((r = read(sock, buf, sizeof buf))) {
if(r < 0) {
  perror("read from socket");
  return 1;
}

copied = 0;
while(copied < r) {
  w = write(1, buf+copied, r-copied);
  if(w < 0) {
perror("write to stdout");
return 1;
  }
  copied += w;
}

if(doselect) {
  fd_set rfds;
  FD_ZERO();
  FD_SET(sock, );
  select(sock+1, , 0, 0, 0);
}
  }

  return 0;
}

-- 
Alan Curry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[Alan Curry]

Christian Lamparter wrote:
> 
> As for carl9170: I'm not sure what the driver or firmware can do about
> this at this time. You can try to disable the hardware crypto by setting
> nohwcrypt via the module option. However, this might not do anything at all.

The nohwcrypt parameter didn't make any difference.

> > 
> > lsusb identifies my network device as:
> > 
> > Bus 005 Device 004: ID 0cf3:1002 Atheros Communications, Inc. TP-Link 
> > TL-WN821N v2 802.11n [Atheros AR9170]
> > 
> > I have version 1.9.9 of carl9170-1.fw in /lib/firmware
> Just one additional question: Is the TL-WN821N connected to a USB3 port?

It never has been before. I tried it today and it made no difference.

-- 
Alan Curry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

PROBLEM: network data corruption (bisected to e5a4b0bb803b)

[Alan Curry]

[1.] One line summary of the problem:
network data corruption (bisected to e5a4b0bb803b)

[2.] Full description of the problem/report:
Note: although my bisect ended at a commit from before 3.19, I have the
same symptom in all newer kernels I've tried, up to 4.6.4.

The commit was:

>commit e5a4b0bb803b39a36478451eae53a880d2663d5b
>Author: Al Viro 
>Date:   Mon Nov 24 18:17:55 2014 -0500
>
>switch memcpy_to_msg() and skb_copy{,_and_csum}_datagram_msg() to 
> primitives

The symptom is that downloaded files (http, ftp, and probably other
protocols) have small corrupted segments (about 1-2 kilobytes long) in
random locations. Only downloads that sustain a high speed for at least a
few seconds are corrupted. Anything small enough to be received in less
than about 5 seconds is not affected.

If I download the same file twice in a row, the corruption is in different
places in each copy.

If I try to do a git clone, it fails a few seconds into the "Receiving
objects" stage with a deflate error.

[3.] Keywords: networking, carl9170

[4.] Kernel information
[4.1.] Kernel version (from /proc/version):
Multiple versions are known to be affected, from 3.19 to 4.6.4

[4.2.] Kernel .config file:
For testing I built with make x86_64_defconfig followed by enabling the
carl9170 driver, which adds these lines:
CONFIG_ATH_COMMON=m
CONFIG_ATH_CARDS=m
CONFIG_CARL9170=m
CONFIG_CARL9170_LEDS=y
CONFIG_CARL9170_WPC=y

[5.] Most recent kernel version which did not have the bug:
That would be the predecessor of e5a4b0bb803b39a36478451eae53a880d2663d5b
which is v3.18-rc6-1620-g17836394e578

[6.] no Oops

[7.] A small shell script or example program which triggers the
 problem (if possible)

This command fails reliably for me when running an affected kernel:

git clone git://git.kernel.org/pub/scm/git/git.git

(I'm including all the standard format stuff suggested by REPORTING-BUGS,
but I think you can skip from here to section 8.7 without missing anything
relevant)

[8.] Environment
[8.1.] Software (add the output of the ver_linux script here)

Mostly Debian 8.5 stable packages here.

GNU C   4.9.2
GNU Make4.0
Binutils2.25
Util-linux  2.25.2
Mount   2.25.2
Quota-tools 4.01
Linux C Library 2.19
Dynamic linker (ldd)2.19
Procps  2.0.11
Kbd 1.15.5
Console-tools   1.15.5
Sh-utils8.23
Modules Loaded  

[8.2.] Processor information (from /proc/cpuinfo):
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Pentium(R) CPU G620 @ 2.60GHz
stepping: 7
microcode   : 0x14
cpu MHz : 1599.914
cache size  : 3072 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave lahf_lm epb 
tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm arat pln pts
bugs:
bogomips: 5188.45
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 42
model name  : Intel(R) Pentium(R) CPU G620 @ 2.60GHz
stepping: 7
microcode   : 0x14
cpu MHz : 2340.304
cache size  : 3072 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 13
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm 
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc 
aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 
xtpr pdcm pcid sse4_1 sse4_2 popcnt tsc_deadline_timer xsave lahf_lm epb 
tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm arat pln pts
bugs:
bogomips: 5189.38
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

[8.3.] Module information (from /proc/modules):

When I tested with the x86_64_defconfig + carl9170 kernel, there were
hardly any modules built, and I reproduced the problem after booting with
init=/bin/sh, so no unnecessary modules were loaded. Currently running a
normal 4.6.4 kernel which is showing the 

Re: rtl8xxxu 4.4.5(from f23): I get a panic adding a new device to the driver

[Alan Stern]

On Thu, 17 Mar 2016, poma wrote:

> On 17.03.2016 19:02, Jes Sorensen wrote:
> > Jes Sorensen <jes.soren...@redhat.com> writes:
> >> Xose Vazquez Perez <xose.vazq...@gmail.com> writes:
> >>> Hi,
> >>>
> >>> If I do:
> >>> # echo "0bda 8176" > /sys/bus/usb/drivers/rtl8xxxu/new_id
> >>
> >> Hi Xose,
> >>
> >> Yes please don't do that. The rtl8xxxu driver relies on the .driver_info
> >> field in struct use_device_id to carry information for the different
> >> types of devices. If you hot add a device like above, the driver will
> >> fail because that field now contains a NULL pointer.
> >>
> >> I should probably add a check for it in the probe function, but it will
> >> simply be there to spit out a warning that it doesn't work to hot add a
> >> device like this.
> >>
> >> If you build it with CONFIG_RTL8XXXU_UNTESTED the 0bda:8176 should be
> >> included in the device list.
> >>
> >> Cheers,
> >> Jes
> > 
> > Hi Xose,
> > 
> > I added the following patch to my tree to avoid this.
> > 
> > Cheers,
> > Jes
> > 
> > commit 9202f4947aac1d60084ee79c9b5294eb42ba59dc
> > Author: Jes Sorensen <jes.soren...@redhat.com>
> > Date:   Thu Mar 17 13:53:48 2016 -0400
> > 
> > rtl8xxxu: Fix OOPS if user tries to add device via /sys
> > 
> > This driver relies on driver_info in struct usb_device_id, hence
> > adding a device via  /sys/bus/usb/drivers/rtl8xxxu/new_id would result
> > in a NULL pointer dereference.
> > 
> > Instead print a message and return -ENODEV
> > 
> > Reported-by: Xose Vazquez Perez <xose.vazq...@gmail.com>
> > Signed-off-by: Jes Sorensen <jes.soren...@redhat.com>
> > 
> > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c 
> > b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> > index 8d893f4..55fc00e 100644
> > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu.c
> > @@ -9671,6 +9671,15 @@ static int rtl8xxxu_probe(struct usb_interface 
> > *interface,
> >  
> > udev = usb_get_dev(interface_to_usbdev(interface));
> >  
> > +   if (!id->driver_info) {
> > +   dev_warn(>dev,
> > +"rtl8xxxu relies on driver_info in struct 
> > usb_device_id.\n");

You should leave out this line.  It won't mean anything to the general
user.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] rt2x00: unterminated strlen of user data

[Alan]

The buffer needs to be zero terminated in case the user data is not.
Otherwise we run off the end of the buffer.

Signed-off-by: Alan Cox <a...@linux.intel.com>
---
 drivers/net/wireless/ralink/rt2x00/rt2x00debug.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c 
b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
index 25ee3cb..72ae530 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
@@ -478,7 +478,7 @@ static ssize_t rt2x00debug_write_##__name(struct file 
*file,\
 {  \
struct rt2x00debug_intf *intf = file->private_data; \
const struct rt2x00debug *debug = intf->debug;  \
-   char line[16];  \
+   char line[17];  \
size_t size;\
unsigned int index = intf->offset_##__name; \
__type value;   \
@@ -494,7 +494,8 @@ static ssize_t rt2x00debug_write_##__name(struct file 
*file,\
\
if (copy_from_user(line, buf, length))  \
return -EFAULT; \
-   \
+   line[16] = 0;   \
+   \
size = strlen(line);\
value = simple_strtoul(line, NULL, 0);  \
\

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4] Add max_tx_power member to set max transmission power for WLAN.RM.2.0 firmware.

[Alan Liu]

WLAN.RM.2.0 firmware use max_tx_power instead of using
max_reg_power to set transmission power. The tx power was about -50dbm, after
 applying this change, it become -32dbm.

Signed-off-by: Alan Liu <alan...@qca.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
 drivers/net/wireless/ath/ath10k/wmi.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index e6d6b42..b3997b5 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1569,7 +1569,7 @@ void ath10k_wmi_put_wmi_channel(struct wmi_channel *ch,
ch->max_power = arg->max_power;
ch->reg_power = arg->max_reg_power;
ch->antenna_max = arg->max_antenna_gain;
-
+   ch->max_tx_power = arg->max_power;
/* mode & flags share storage */
ch->mode = arg->mode;
ch->flags |= __cpu_to_le32(flags);
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 
b/drivers/net/wireless/ath/ath10k/wmi.h
index 0d4efc9..a56cf27 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -1709,6 +1709,7 @@ struct wmi_channel {
__le32 reginfo1;
struct {
u8 antenna_max;
+   u8 max_tx_power;
} __packed;
} __packed;
 } __packed;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

10ec:b723 [HP Notebook - 15-ac106na] Wifi unstable NO HTML

[Alan]

 sorry guys my first bug report
[1.]
Bug #1516251 10ec:b723 [HP Notebook - 15-ac106na] Wifi unstable

[2.]
Networks not detected unless router is within 2feet
weak signal strength, connection dropping [when it does connect]
device dropping [disappearing from NetworkManager]

only affects this wireless device [rtl8723be] all others function as expected

###Irq error for i915 graphics is fixed in 4.2.6 and this error still
occurs in that kernel

bios F.1A [latest]

router:-
Virgin superhub
software version V2.39.02 [latest]
bootcode version 2.3.0beta7

[3.]

[4.]
Linux version 4.4.0-rc1 (al@n) (gcc version 4.9.2 (Ubuntu
4.9.2-10ubuntu13) ) #1 SMP Mon Nov 16 10:52:31 GMT 2015#

[5.]
No oops but i do get this line in dmesg in 4.4-Rc only, possible my
error compiling?? [NOOB]
[   15.734897] rtl8723be :0d:00.0 wlan0: set_features() failed
(-1); wanted 0x4000, left 0x4800

[6.]
happens every boot

[7.]
Description:Ubuntu 15.04
Release:15.04

[7.1]
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux n 4.4.0-rc1 #1 SMP Mon Nov 16 10:52:31 GMT 2015 x86_64 x86_64
x86_64 GNU/Linux

GNU C   4.9.2
GNU Make4.0
Binutils2.25
Util-linux  2.25.2
Mount   2.25.2
Module-init-tools   18
E2fsprogs   1.42.12
Pcmciautils 018
PPP 2.4.6
Linux C Library 2.21
Dynamic linker (ldd)2.21
Linux C++ Library   6.0.20
Procps  3.3.9
Net-tools   1.60
Kbd 1.15.5
Console-tools   1.15.5
Sh-utils8.23
Udev219
Wireless-tools  30
Modules Loaded  8250_dw acpi_pad acpi_thermal_rel ahci arc4
autofs4 binfmt_misc bluetooth bnep btbcm btcoexist btintel btrtl btusb
cfg80211 coretemp crc32_pclmul crct10dif_pclmul drm drm_kms_helper
dw_dmac dw_dmac_core fb_sys_fops fjes hid hid_generic hp_wireless
hp_wmi i2c_algo_bit i2c_designware_core i2c_designware_platform
i2c_hid i915 input_leds int3400_thermal int3402_thermal
int3403_thermal int340x_thermal_zone intel_pch_thermal
intel_powerclamp intel_rapl intel_soc_dts_iosf iosf_mbi irqbypass
joydev kvm kvm_intel libahci lp lpc_ich mac80211 mac_hid media mei
mei_me mii nls_iso8859_1 parport parport_pc ppdev
processor_thermal_device psmouse r8169 rfcomm rtl8723be rtl8723_common
rtl_pci rtlwifi sdhci sdhci_acpi serio_raw shpchp snd snd_hda_codec
snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_codec_realtek
snd_hda_core snd_hda_intel snd_hwdep snd_pcm snd_rawmidi snd_seq
snd_seq_device snd_seq_midi snd_seq_midi_event snd_soc_core
snd_soc_rl6347a snd_soc_rt286 snd_soc_ssm4567 snd_soc_sst_acpi
snd_timer soundcore sparse_keymap spi_pxa2xx_platform syscopyarea
sysfillrect sysimgblt tpm_crb usbhid uvcvideo v4l2_common video
videobuf2_core videobuf2_memops videobuf2_v4l2 videobuf2_vmalloc
videodev wmi x86_pkg_temp_thermal

[7.2]
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Pentium(R) CPU 3825U @ 1.90GHz
stepping: 4
microcode   : 0x21
cpu MHz : 1900.000
cache size  : 2048 KB
physical id : 0
siblings: 4
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq
dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid
sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer xsave rdrand
lahf_lm abm 3dnowprefetch ida arat epb pln pts dtherm intel_pt
tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust erms invpcid
rdseed xsaveopt
bugs:
bogomips: 3791.26
clflush size: 64
cache_alignment : 64
address sizes   : 39 bits physical, 48 bits virtual
power management:

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 6
model   : 61
model name  : Intel(R) Pentium(R) CPU 3825U @ 1.90GHz
stepping: 4
microcode   : 0x21
cpu MHz : 1845.152
cache size  : 2048 KB
physical id : 0
siblings: 4
core id : 1
cpu cores   : 2
apicid  : 2
initial apicid  : 2
fpu : yes
fpu_exception   : yes
cpuid level : 20
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts
rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq
dtes64 monitor ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm pcid
sse4_1 

Re: PROBLEM: rtlwifi drops most IPv6 packets

[Alan Fisher]

On 02/17/2015 08:43 AM, Larry Finger wrote:

On 02/17/2015 02:29 AM, Alan Fisher wrote:

Larry,


I am guessing that you have an RTL8188CE, which uses rtl8192ce.


Yep, my wireless card is an RTL8188CE

The purpose of rtl_is_special_data() is to ensure that management 
packets have
the highest probability of being successfully transmitted by sending 
them at a

low rate.

...
It also occurs to me that mac80211 probably handles this function, 
and that it

may be possible to remove this routine, which is essentially what your
workaround does.
I couldn't find any information on mac80211 treating certain packets 
(ARP, DHCP,
etc...) as special. It does seem to handle automatic rate selection, 
though. I
would think that would be enough to handle packet loss reasonably 
well. I
believe the protocols tested for here all have mechanisms for 
handling lost
packets. I also can't find any other 802.11 drivers which try to 
handle DHCP
packets in a special way. I think it would be safe to remove this 
routine. I

have a patch to do that, if you're okay with that change.


The story is a bit more complicated. These drivers use firmware rate 
selection, not the ones in mac80211. At this point, I would not be 
comfortable with removing the entire routine.

Ok, makes sense.


Regarding the patch, this change:

-} else if (0x86DD == ether_type) {
-return true;
  }

successfully prevents IPv6 packets from being treated as special (and 
thus

dropped).

However, this:
+if (ETH_P_IP == ether_type || ETH_P_IPV6 == ether_type) {
  ip = (struct iphdr *)((u8 *)skb-data + offset +

seems to be reading an IPv4 header (struct iphdr) from an IPv6 
packet. I believe

a struct ipv6hdr should be used here.


You are correct. My patch was prepared too hastily.

If we are to continue handling certain types of packets differently, 
IPv6
neighbor solicitation messages (like ARP in IPv4) and IPv6 router 
discovery
messages (stateless IPv6 autoconfig, similar to DHCP in IPv4 
networks) should
probably be added to the list to maintain consistency with what is 
being handled

for IPv4. These are both variants of ICMPv6 packets, although generally
transmitting all ICMPv6 packets at the lowest rate is probably a bad 
idea, as
ICMP echo is commonly used to measure network performance and should 
be treated

the same as normal traffic.


For the moment, I think we need to return false, not true, for all 
IPv6 packets until a more complete solution is found. Does the 
attached patch fix the problem you are seeing? I do not have an IPv6 
compliant ISP, thus I cannot do much testing.
Yes, IPv6 appears to work normally with that patch applied. I recently 
spoke with someone who uses RTL8188 under Linux 3.18, and doesn't see 
any packet loss with special packets. I would guess this is because he 
has a slightly different hardware configuration (different processor, 
etc..).




Larry



Thanks,
Alan
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: PROBLEM: rtlwifi drops most IPv6 packets

[Alan Fisher]

Larry,


I am guessing that you have an RTL8188CE, which uses rtl8192ce.


Yep, my wireless card is an RTL8188CE


The purpose of rtl_is_special_data() is to ensure that management packets have 
the highest probability of being successfully transmitted by sending them at a 
low rate.

...

It also occurs to me that mac80211 probably handles this function, and that it 
may be possible to remove this routine, which is essentially what your 
workaround does.

I couldn't find any information on mac80211 treating certain packets (ARP, 
DHCP, etc...) as special. It does seem to handle automatic rate selection, 
though. I would think that would be enough to handle packet loss reasonably 
well. I believe the protocols tested for here all have mechanisms for handling 
lost packets. I also can't find any other 802.11 drivers which try to handle 
DHCP packets in a special way. I think it would be safe to remove this routine. 
I have a patch to do that, if you're okay with that change.

Regarding the patch, this change:

-   } else if (0x86DD == ether_type) {
-   return true;
}

successfully prevents IPv6 packets from being treated as special (and thus 
dropped).

However, this:
+   if (ETH_P_IP == ether_type || ETH_P_IPV6 == ether_type) {
ip = (struct iphdr *)((u8 *)skb-data + offset +

seems to be reading an IPv4 header (struct iphdr) from an IPv6 packet. I 
believe a struct ipv6hdr should be used here.

If we are to continue handling certain types of packets differently, IPv6 
neighbor solicitation messages (like ARP in IPv4) and IPv6 router discovery 
messages (stateless IPv6 autoconfig, similar to DHCP in IPv4 networks) should 
probably be added to the list to maintain consistency with what is being 
handled for IPv4. These are both variants of ICMPv6 packets, although generally 
transmitting all ICMPv6 packets at the lowest rate is probably a bad idea, as 
ICMP echo is commonly used to measure network performance and should be treated 
the same as normal traffic.

Thanks,
Alan

On 02/16/2015 10:26 AM, Larry Finger wrote:

On 02/16/2015 01:35 AM, Alan Fisher wrote:

Alan,

I looked at the routine, and it is returning true for all IPv6 packets.

Does the attached patch for 3.18 or 3.19 help?

Larry



--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

PROBLEM: rtlwifi drops most IPv6 packets

[Alan Fisher]

Hello!

I have a machine with a Realtek RTL8188 wireless card. This card is 
handled by the rtl8192 driver. The driver in kernel 3.16.0-4 causes most 
sent ARP packets to be dropped. ARP packets appear to get through with 
the driver in kernel 3.19, but IPv6 packets suffer instead. I have 
reproduced this when connected to multiple access points.


I think I have traced this issue to some code in the rtlwifi driver that 
does special handling on special packets. The function 
rtl_is_special_data() in base.c determines whether a packet is 
considered special. In the 3.16 kernel, this includes ARP packets, 
wireless encryption packets, and DHCP/BOOTP packets. IPv6 appears to 
have been added to this list as of kernel 3.19.


It seems the idea is that certain important packets should be 
transmitted at the lowest possible 802.11 rate. The 
rtl_is_special_data() function is used to determine which packets to 
handle this way. Not treating any packets as special, by adding a 
return false; at the beginning of rtl_is_special_data(), seems to fix 
the problems with lost packets with both kernels.


I would guess that some good reason exists for this special handling, 
but I can't determine what it is. I couldn't find anything similar in 
iwlwifi. Either way, it seems like a bug to send all IPv6 traffic at the 
lowest possible rate, successful or not.


-Alan
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Soft lockup in 3.17-rc7 when using PPP over L2TP over IPSEC

[Alan Stern]

 becomes useless.

I don't know if the problem is in the networking core or in the 
wireless driver.  If anyone wants, I can try testing using a wired 
Ethernet connection.

Note: This problem is not new.  It has been happening for at least the
last several kernel versions -- in fact, I don't know if this has ever
worked.

Can this be debugged and fixed?

Alan Stern

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html