Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
I am having a rather strange problem when it comes to UDP datagrams in linux. I have found that when running software on linux that listens for multicast traffic on a given address, linux is having trouble receiving large UDP datagrams. I know what everyone is thinking, I must be loosing packet fragments along the way due to maybe a busy network, but this is not the case. When I run ethereal on the machine, I can see that all of the fragments are getting to the machine, but to the application. It is like they are't even there. To make things worse, when running the same software on windows(EEEK), everything works fine. To test out the problem, I have written two very basic java classes. One class sends out generic packets of a given size and the other class simply listens over the network and notifies you once a packet has been received. I then ran the receiving class on several versions of linux to determine the size boundary of each system. By slowly adjusting the size of the packets sent I have determined that Redhat 9 has a boundary of 41,433 bytes. If you were to send data in the size of 41,432 bytes, everything is fine, but not 41,433. The boundary information for each other version of linux can be found below. Now to me, I would assume that each OS would be able to handle packet sizes up until the industry standard 65k. I am puzzled as to why this would be happening. It looks as if Fedora Core 2 is no longer having this issue and Slackware 10.1 also does not experience this problem. I will eventually need to be able to receive packets of up to 57000 kb, but I would like to avoid running fedora core 2 if I can avoid it. Has anyone seen this before or possibly know what I could do to fix it? Do I need to adjust an OS setting? Any help or ideas would be greatly appreciated. Thank You.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |