Date: Thu, 14 May 2009 12:03:55 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Daniel O'Connor <doconnor@gsoft.com.au> Cc: freebsd-bluetooth@freebsd.org Subject: Re: btpand example Message-ID: <1242299035.690452.893.nullmailer@galant.ukfsn.org> In-Reply-To: <200905141920.47717.doconnor@gsoft.com.au> References: <200905141438.17380.doconnor@gsoft.com.au> <1242289912.789883.948.nullmailer@galant.ukfsn.org> <200905141920.47717.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 14 May 2009, Daniel O'Connor wrote: > On Thu, 14 May 2009, Iain Hibbert wrote: > > On Thu, 14 May 2009, Daniel O'Connor wrote: > > > Also, I found the MTU by trial and error, 600 works for me, 650 > > > does not. I am guessing this is a bluetooth thing but I'm not > > > sure.. If it is would it be possible for btpand to set the MTU? > > > > Why did you think to change the MTU and what was the failure? > > I found that pinging worked and I could connect to an SSH port but they > SSH key exchange stalled so I guessed MTU and got lucky. Hm, I do manage to use ssh successfully over a btpand/winmobile link.. > I later tried l2ping -s 1500 -a pda and it worked so I'm not sure what's > going on. probably better to try actual ping with larger packet sizes..? l2ping only tests the bluetooth link. If you also added a log_debug() to the end of bnep_send() to display the nw and pkt->len values you might see if lossage was happening at any particular packet size. There is already a check that the packet doesn't exceed the MTU of the link though. > I have done the same operation on the same hardware in Linux and it > worked without MTU tweaks, however I haven't looked to see what MTU it > used or anything. I do get a weird problem sometimes where incoming ethernet packet payload is rejected by tap for being oversized. I've never tracked it down but I'm blaming windows mobile for that because the ethernet packet probably originates there rather than at the other end of the GPRS link (I could be wrong) eg May 2 11:06:36 galant btpand[820]: bnep_recv: received long packet (type=0x02, proto=0x0800, len=1568) May 2 11:06:36 galant /netbsd: tap0: discarding oversize frame (len=1582) I find this will cause a HTTP transfer to stall but I think ssh recovers from the lost packet ok. iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1242299035.690452.893.nullmailer>