Re: Need some clarification or help

[Christian Riechmann <riechmann@fgan.de>]

Hello Jee,

On 2004-04-22 22:34:59 +0100, Jee J.Z. wrote:
> >
> > In my opinion the surplus bytes are not more part of the packet, because
> > I gave the new length as parameter of the ipq_set_verdict call. I do not
> > know any other method to get rid of them. Do you have an idea?
> > The fact that the surplus bytes are partly the same as of the original
> > packet can be explined: My program strips the IP, UDP and some
> > encapsulation bytes.
> 
> I would guess there could be some misoperation on your memory. I don't
> understand why stripping the IP, UDP and some encapsulation bytes result in
> these duplicated surplus bytes.

Nobody is perfect, but for the moment I did not find the error.(:=((

> 
> It should not be hard to get rid of these constant bytes. Just find out
> where they are in your memory, get rid of them  -- put all your useful bytes
> in a consecutive memory block (if these surplus bytes are not the end of the
> packet), or double check and confirm the length of useful bytes (as data_len
> in ipq_set_verdict()) if these surplus bytes are the end of the packet.

To a certain extent my code does this: 
After finding out that the inner packet has to be accepted I set the
char *buf parameter of the verdict call to the beginning of inner packet,
the size_t data_len parameter is set to length of the inner packet.
Therefore it seems to me that the verdict call copies the inner packet
to the beginning of the captured packet.

> 
> BTW, Did you copy all the packet content into userspace by setting
> IPQ_COPY_PACKET in ipq_set_mode function?

Yes!

> 
> > >
> > > > For your info I attach a file including the commented sequence of the
> > > > packet flow from sender to receiver.
> > >
> > > As you know, TCP, UDP, and ICMP checksums are calculated based on both
> their
> > > header and their payload, unlike IP. Therefore, these additional bytes
> in
> > > your trace may result in the checksum calculation incorrectness. I
> assume
> > > you don't have these additional bytes when you tested on UDP and ICMP
> > > packets.
> >
> > No, in both cases they are there, but that has no bad effect. Therefore
> > my assumption that the calculation of the TCP checksum includes all
> > remaining bytes at the end.
> 
> Sounds strange. TCP checksum does include all its payload data. However, UDP
> and ICMP do so as well. The only possibility I can see is when you test on
> UDP and ICMP packets, the system doesn't think the surplus bytes are part of
> the packets; instead, the system may think they the packet trailer. But when
> you test on TCP packets, the system thinks the surplus bytes are part of the
> packets, and therefore the checksum is not correct. Did you change the
> header length field and total length field in IP header?

I agree completely to your assumption or interpretation. Unfortunately I
am not so familiar with the kernel, therefore I have not yet analyzed
the TCP code for incomming packets.
As pointed out above, I do not change anything within the inner packet.

> 
> > On the other hand, I do not understand why after the verdict call the
> > packet holds the surplus bytes. Maybe this should be fixed?
> 
> To test, try shorten the data_len parameter in ipq_set_verdict() and see
> whether they are still there.

As mentioned above, this is exactly what I do.

> 
> I am looking forward to your result.

It seems to me I have to learn why verdict does not reduce the packet
size and how the kernel handles incomming TCP packets concerning
checksumming. If you have further ideas, please mail them.
Nevertheless I have set up a bug report, hoping that one of the
core group can solve the problem.

Regards

Christian
-- 
Christian Riechmann    E-Mail: riechmann@fgan.de
c/o FGAN/FKIE          Tel: (+49) 228/9435 345,378
Neuenahrer Strasse 20  Fax: (+49) 228/9435 685
D-53343 Wachtberg, Germany