There's a Linux kernel option that enables UDP MTU discovery. If turned
on, then the kernel will try to discover the minimum MTU to each target
IP address and return an error code if you try to send a packet that's
too big. (If turned off it'll fragment UDP packets instead.) You might
be running into this, although it's suspicious that you're not seeing an
error code --- it's supposed to return an EMSGSIZE error in this situation.
(1472 bytes is the amount of UDP payload you get in a 1500 byte ethernet
frame.)
See the udp and ip man pages for details.
--
┌─── dg@cowlark.com ───── http://www.cowlark.com ─────
│
│ "They laughed at Newton. They laughed at Einstein. Of course, they
│ also laughed at Bozo the Clown." --- Carl Sagan
1500 bytes is the length of an ethernet frame, but it's become
something of a standard. hence it's no surprise that you're not
seeing any joy sending UDP packets over that length.
why are you using UDP? :-)
(usually it's used for situations where the loss of a packet here and
there is not that important, like streaming A/V content etc.)
>Use ifconfig to find out about the MTU size of your interface.
--
jason.vp.engineering.particle
I thought he said "basic" network functions (Ash?), like send/sendto...
EMSGSIZE is only supposed to be returned when the packet transmission
is required to be atomic, and this requirement is imposed by the
socket. UDP is as well fragmentable as TCP, IMHO you need to care for
fragmentation only when you dealing with raw IP sockets (can't really
do that on Android, being non-root and all).
Btw, AFAIK, packets, while fragmented, are IP packets, as
fragmentation information is a part of IP header. Kernel is supposed
to read all fragmented packets, in any order, including the master one
that has UDP header, and assemble them, or throw them away, if all
fragments aren't received within a timeout.
Being a stickler about these things, I've ran this
(http://manticore.2y.net/temp/udp-send.c) on a Linux desktop, with 10k
byte buffer, and enjoyed tcpdump displaying nicely fragmented packets
on both sending and receiving sides (and dissappointed in netcat,
since for some reason it only reads first 1000bytes). Interfaces on
both systems had 1,500 MTU.
So, the questions to Ash are: what syscalls are you using to send
data, what network are they coming over, and where are you running
tcpdump?
I wouldn't be surprised if the carrier network, or default device
configuration blackholes fragmented UDP packets, for example, but I
see no reason why wouldn't this work over WiFi, or USB link.
P.S.
Yes, using UDP is ineffective due to packet loss, especially
ineffective if you fragment them, but that's not really the point, it
should still work reasonably reliable.
Thanks,
Pawel.
On Thu, Sep 10, 2009 at 10:04 AM, Roman ( T-Mobile USA)
<roman.bau...@t-mobile.com> wrote:
>
> Use ifconfig to find out about the MTU size of your interface.
>
[skipped]
I'll see what I can figure out.
In the mean time, could you run tcpdump on the emulator, and see what
it shows up?
Also, make sure that you don't filter 'udp' protocol, best is to see
all the traffic, since UDP frags may not be recognized as UDP packets.
tcpdump for android can be found here:
http://junxian-huang.blogspot.com/2009/03/finally-tcpdump-on-gphone-g1-android.html
Thanks,
Pawel.
Jason Proctor wrote:
> UDP is datagram service. IP itself won't do fragmentation and
> reassembly of UDP packets, that's what TCP is there for. each
> individual datagram has to be self-contained, as any packet might be
> lost in transport and the receiver has to be able to determine state
> from anywhere in the "stream".
what?
It's true that IPv6 won't do fragmentation, but IPv4 certainly does.
It's done it for UDP packets since the dawn of time.
I think you should read RFC791 and RFC792.
- --
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
then sign the petition.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Finger me for keys
iQEVAwUBSszV84CLcPvd0N1lAQJm6gf8DOKUACACsM9DnzuGbdbjorXlWMmhTnch
OGv5rxgDcrF6fWc7hrXXTXA0zjYfaWrl4pm3AvbSWyOXFI5ACSY/ZNSIY6NW68qX
OWJys7ts31sPPKank6yDgTOSIPRMVvfSTpYU8j+TJaGx6ypQ2uB/JmKMjuPtE4xx
5nsHH2vbR5CkFyDWnRjTFk7scRFzdtG48QYSIRnFwqLXEot6MwcVfSXX/YgmGxPF
v9pNDPuuA5Vtmm7XP3VAQst/tjAj/EwvDt3gEhRDQyegYqqMOFd5FN0p/eaA7rcX
F/C2ncArI/OwKZ8aICEubcbREMcpt4EmDQYauQoKjF0jYVU5Pt4Ppw==
=9cl1
-----END PGP SIGNATURE-----