Dear All,
I have discovered a regression in f_phonet. I am trying to send/receive
data through a socket of SOCK_DGRAM type.
I enclose a program which I use to send and receive the data.
First, I configure the phonet using the tools found here:
git://git.gitorious.org/meego-cellular/phonet-utils.git.
On the host (PC):
$ phonet -a 0x10 -i usbpn0
$ pnroute add 0x6c usbpn0
$ pnroute add 0x10 usbpn0
$ ifconfig usbpn0 up
On the device (ARM):
$ phonet -a 0x6c -i upnlink0
$ pnroute add 0x10 upnlink0
Second, I run the attached pnxmit:
On the device:
$ pnxmit -a 0x6c -r
On the host:
$ pnxmit -a 0x10 -s 0x6c
I then expect to see "Received 263 bytes from 10ab" on the device.
But it does not happen. Instead, in net/phonet/af_phonet.c
the packets are dropped in phonet_rcv, so they never reach any socket.
An incoming packet fails to satisfy the condition
if ((len > skb->len) || pskb_trim(skb, len))
because len has an unnaturally large value.
There is a commit f5a45325 introduced between 2.6.37 and 2.6.38, which
deals with struct sk_buff fragments. If I revert it using the patch
sent together with this cover letter (on current kernels the f5a45325
does not revert cleanly), there is no unnaturally large len problem
and the data are delivered to the socket waiting for it.
I also tried the very 2.6.37 and 2.6.38 kernels; on 2.6.38 the mentioned
patch does revert cleanly and it helps the same.
On the other hand, if I run the test using dummy_{hcd|udc} on an ARM machine,
so that it is both the sender and the receiver, this works OK even on
recent kernels.
@Remi: Could you look into the problem? Or is it a problem at all?
Anyone?
Andrzej Pietrasiewicz (2):
Revert "f_phonet: avoid pskb_pull(), fix OOPS with CONFIG_HIGHMEM"
pnxmit.c, test program
drivers/usb/gadget/f_phonet.c | 15 +++++----------
1 files changed, 5 insertions(+), 10 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
