Date: Sat, 16 May 2009 15:13:42 +0930 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: Iain Hibbert <plunky@rya-online.net> Cc: freebsd-bluetooth@freebsd.org Subject: Re: btpand example Message-ID: <200905161513.43690.doconnor@gsoft.com.au> In-Reply-To: <1242299035.690452.893.nullmailer@galant.ukfsn.org> References: <200905141438.17380.doconnor@gsoft.com.au> <200905141920.47717.doconnor@gsoft.com.au> <1242299035.690452.893.nullmailer@galant.ukfsn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart3212573.FqtHeI5am1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 14 May 2009, Iain Hibbert wrote: > > 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..?=20 > l2ping only tests the bluetooth link. Sorry, I missed a step before, I did try ICMP pings when trying to work=20 it out. 600 was the largest I found (650 was too large) > 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 can't reproduce the problem now.. Perhaps my phone was out of RAM or=20 something. > > 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=3D0x02, proto=3D0x0800, len=3D1568) May 2 11:06:36 galant /netbsd: > tap0: discarding oversize frame (len=3D1582) I haven't seen that [yet] but I've barely used it. > I find this will cause a HTTP transfer to stall but I think ssh > recovers from the lost packet ok. OK. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart3212573.FqtHeI5am1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (FreeBSD) iD8DBQBKDlKP5ZPcIHs/zowRAgufAKCN9GVE1UIIZHWdn4nn3/gK4uYNwwCgmg7v x7kbQ6ZjkgyOd/unFx7oNEc= =qt15 -----END PGP SIGNATURE----- --nextPart3212573.FqtHeI5am1--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905161513.43690.doconnor>