IP identifier field for linux UDP/IP equals zero??!
ak.linuxsa at topology.org
Thu May 15 10:17:43 CST 2003
On Thu, May 15, 2003 at 10:09:27AM +0930, Mark Newton wrote:
> On Thu, May 15, 2003 at 09:45:07AM +0930, Alan Kennington wrote:
> Alan, you've read (and probably /written/) standards documents before.
> You should know that when the document is silent on some matter, that
> means the implementor is free to do whatever they want.
In this case, the spec was clear. And it was silent on _contradictions_
to the rule. It was not silent on the requirement to put a different
IP ID in every packet.
> You've concluded that it's zero if the DF bit is set; Without looking at
> it in detail, I'd conjecture that it's -actually- zero for unfragmentated
> packets, whether the DF bit is set or not. You're probably in a better
> position to test that than I am.
Actually not. I see constant IP ID = 0 if and only if the DF bit is set.
I don't have the energy to read the kernel source for this right now.
But I will read it.
> > I now have to tell my client that my software will only work as
> > required when the two machines generating voice/video conference packets
> > are not linux. With linux, my software will work at 50% efficiency.
> <shrug> So write your application differently. Unless you're looking
> forward to being able to say, "I wrote the only network application in
> history which works better on Windows than Linux" on your resume'.
But it isn't an application. It's kernel software _below_ IP in the
protocol stack. And it must conform with an RFC. And I intend to write
it in conformance to the RFC - not kludged to work with linux.
If it was a private protocol I was implementing, I'd modify it
to work with linux.
So I will be writing in my report that 50% efficiency will be experienced
in the case of conference source nodes which run linux.
Therefore NetMeeting should be used instead of GnomeMeeting for
purposes of aceptance testing.
I actually _want_ linux to be better in all things.
But the facts are against me in this case.
By the way, ethereal has turned out to be a real star in this work
I'm doing right now. It's got a great range of application protocol
interpreters and a user-friendly way to associate them with streams.
It does a stunning job on RTP and RTCP protocols.
That's saved me weeks of work.
For a while I stopped using ethereal because it used to be stodgy.
Now it's a real pleasure to use.
I was also delighted by the functionality of another chunk of
free software - ohphone (OpenH323), which I believe is written
by an Australian company. This has built-in stats info which is
excellent for people developing software.
So the free-software applications have worked delightfully, but
the linux kernel has an "issuse".
I guess I'll fight it out in the kernel developers' mailing list
as soon as I get some spare time and energy.
LinuxSA WWW: http://www.linuxsa.org.au/ IRC: #linuxsa on irc.freenode.net
To unsubscribe from the LinuxSA list:
mail linuxsa-request at linuxsa.org.au with "unsubscribe" as the subject
More information about the linuxsa