On Wednesday, May 01, 2013 1:53 PM Daniele Forsi wrote: > 2013/4/30 Andrzej Pietrasiewicz: > > > As I already wrote I am now stuck with sending correct data, so that > when > > I sendto() from host I can recvfrom() on device (or vice versa). > > payload data doesn't matter so you don't need my dumps, maybe you are > using the same address on both sides of the link or you are sending to > the wrong address or the route isn't set up correctly > This is how I set up the host and the device, using the tools from Rémi (http://gitorious.org/meego-cellular/phonet-utils/trees/master): Device: $ ./phonet -a 0x6c -i upnlink0 $ ./phonet -l -i upnlink0 phonet addr: 6c $ ./pnroute add 0x10 upnlink0 $ ./pnroute 10 upnlink0 $ ifconfig upnlink0 up Host: $ ./phonet -a 0x10 -i usbpn0 $ ./phonet -l -i usbpn0 phonet addr: 10 $ ./pnroute add 0x6c usbpn0 $ ./pnroute add 0x10 usbpn0 $ ./pnroute 10 usbpn0 6C usbpn0 $ ifconfig usbpn0 up I attach the test program I use. So far I have learnt that if I do $ ./pnxmit -a 0x10 -s 0x6c on the host, I can see that on the device the pn_rx_complete (drivers/usb/gadget/f_phonet.c) is called, then netif_rx (net/core/dev.c), then packet_type->func [phonet_rcv] (net/phonet/af_phonet.c). The phonet_rcv fails at if ((len > skb->len) || pskb_trim(skb, len)) goto out; with len=61182 and skb->len=10. The len looks suspicious, but I don't know why it is set to such a large value. In consequence NET_RX_DROP is returned from phonet_rcv, so I assume no client will ever be able to recvfrom a socket. Any ideas? Andrzej
Attachment:
pnxmit.c
Description: Binary data
