Need some clarification or help

Need some clarification or help

[Christian Riechmann]

Hello,

is it possible to read - via ipq_read/ipq_get_packet - a UDP packetr
and after some changes to accept - via ipq_set_verdict with NF_ACCEPT and
shorter length - it as a TCP packet?

Here is what I wish to do:
For the transmission of IP packets (UDP, ICMP, TCP) between two hosts
I want to send these packets through a UDP tunnel.
On the sender I am using iptables to get all the original packets into user
space for their encapsulation and UDP sending.
In the same way on the receiver I use iptables to get those UDP packets
from the sender enclosing the original packets into user space, where
I decapsulate the original packets and wish to inject these by using
ipq_set_verdict with action set to NF_ACCEPT.
This method works for original packets of type ICMP and UDP, but NOT
for TCP packets.
What I can see from my tcpdump logging on the receiver is:
1.That all three types of original packets are ACCEPTED, but tcpdump
  shows some additional bytes (packet length is still the same as given by
  m->data_len upon the ipq_get_packet call, although the ipq_set_verdict
  call get an updated length).
2.Those original packets of type UDP and ICMP can be read by the intended
  receiver programs but those of type TCP are not presented to the
  intended receiver application.

Below I attach those iptables rules I am using.

# Parameter setting:
#  $1:	Iptable operation "A"
#  $2:  Interface name
#  $3:  IP address of this host
#
# Next rule:
#    Send out all BROADCAST packets
#
#iptables -$1 OUTPUT -o $2 -d 128.7.27.255 --destination-port 140 -j ACCEPT
iptables -$1 OUTPUT -o $2 -d 128.7.27.255 -j ACCEPT

#
# Next rule:
#    Show me all locally generated multicast packets before routing
#
iptables -$1 OUTPUT -o $2 -d 224.0.0.0/4 -j QUEUE

#
# Next rule:
#    Show me all locally generated packets before routing
#
iptables -$1 OUTPUT -o $2 -j QUEUE

#
# Next rule:
#    Show me all UDP packets for port 140 arriving from foreign hosts
#
iptables -$1 INPUT -i $2 -p udp --destination-port 140 -j QUEUE

#
# Next rule:
#    DROP all multicast packet sent by any host except the local one
#
iptables -$1 INPUT -i $2 -s ! $3 -d 224.0.0.0/4 -j DROP


Thanks for any help or clarification.

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

Re: Need some clarification or help

[Antony Stone]

On Tuesday 20 April 2004 7:22 pm, Christian Riechmann wrote:

> Hello,
>
> is it possible to read - via ipq_read/ipq_get_packet - a UDP packetr
> and after some changes to accept - via ipq_set_verdict with NF_ACCEPT and
> shorter length - it as a TCP packet?

My immediate response to this is "no, of course not, because UDP and TCP 
packet headers are completely different".

I mean, UDP packets just get sent - who knows whether the receiver gets them 
or not?   TCP involves a three-way handshake to set up a connection, and then 
sequence & acknowledgement numbers to maintain the reliability.   Creating 
that out of nowhere would be difficult.

> Here is what I wish to do:
> For the transmission of IP packets (UDP, ICMP, TCP) between two hosts
> I want to send these packets through a UDP tunnel.

Tunnelling is a very different matter from converting UDP packets into TCP 
packets, and should be eminently feasible.

http://vtun.sourceforge.net will provide you a general-purpose tunnel which 
operates over UDP.   See if that does what you need - it'll probably simplify 
what you've been attempting to do with netfilter considerably.

Regards,

Antony.

-- 
"640 kilobytes (of RAM) should be enough for anybody."

 - Bill Gates

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Need some clarification or help

[Christian Riechmann]

Antony,

first thanks for your reply and your hint concerning vtun.
I have some remarks to your reply and put them inside your message.

On 2004-04-20 19:47:39 +0100, Antony Stone wrote:
> On Tuesday 20 April 2004 7:22 pm, Christian Riechmann wrote:
> 
> > Hello,
> >
> > is it possible to read - via ipq_read/ipq_get_packet - a UDP packetr
> > and after some changes to accept - via ipq_set_verdict with NF_ACCEPT and
> > shorter length - it as a TCP packet?
> 
> My immediate response to this is "no, of course not, because UDP and TCP 
> packet headers are completely different".
> 
> I mean, UDP packets just get sent - who knows whether the receiver gets them 
> or not?   TCP involves a three-way handshake to set up a connection, and then 
> sequence & acknowledgement numbers to maintain the reliability.   Creating 
> that out of nowhere would be difficult.

Maybe I am a little bit lazy when describing my method as "tunnelling". 
Therefore I will go a little bit deeper. 
I know that UDP and TCP protocols are completely different, especially
the 3-way handshake. But all its steps are TCP packets. Therefore my idea
is to encapsulate on each side each TCP packet into a UDP packet, send
this one to the other side, decapsulate the original TCP paket from the UDP
packet and inject the TCP packet to the kernel. This way the total TCP
dialog shall be exchanged as payload of separate UDP packets. UDP
is necessary, because only UDP can use broadcast addresses. 
(I use this type of address to emulate LAN-broadcast within a mobile
adhoc network. Therefore I doubt that vtun would help me.)

> 
> > Here is what I wish to do:
> > For the transmission of IP packets (UDP, ICMP, TCP) between two hosts
> > I want to send these packets through a UDP tunnel.
> 
> Tunnelling is a very different matter from converting UDP packets into TCP 
> packets, and should be eminently feasible.

As I tried to explain, I do NOT want to convert UDP to TCP, I only want to
transport TCP packets as UDP payload.

I would be glad if you can comment the method described above.

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

Re: Need some clarification or help

[Antony Stone]

On Tuesday 20 April 2004 9:51 pm, Christian Riechmann wrote:

> I know that UDP and TCP protocols are completely different, especially
> the 3-way handshake. But all its steps are TCP packets. Therefore my idea
> is to encapsulate on each side each TCP packet into a UDP packet, send
> this one to the other side, decapsulate the original TCP paket from the UDP
> packet and inject the TCP packet to the kernel.

Okay - that sounds to me like a UDP tunnel through which you are sending TCP 
packets - I agree.

> This way the total TCP dialog shall be exchanged as payload of separate UDP
> packets. UDP is necessary, because only UDP can use broadcast addresses.
> (I use this type of address to emulate LAN-broadcast within a mobile
> adhoc network. Therefore I doubt that vtun would help me.)

I don't quite understand how this would work.   You say you want to use UDP 
broadcasts - which suggests to me one sender and many receivers.   TCP cannot 
work with that, because each receiver is going to want to send 
acknowledgement packets back to the sender, which will get confused about who 
is it communicating with.

TCP is basically a one-to-one protocol, and even if you try putting the 
packets inside UDP packets which can be broadcast to multiple receivers, TCP 
is still going to want to communicate between one machine at each end.

Ultimately you have to regard the UDP tunnel as just another route to 
somewhere, and TCP will use all routes in the same way - to find one machine 
at the other end.

Have I understood correctly what you wanted to do?

Regards,

Antony.

-- 
"Linux is going to be part of the future. It's going to be like Unix was."

 - Peter Moore, Asia-Pacific general manager, Microsoft

                                                     Please reply to the list;
                                                           please don't CC me.

Re: Need some clarification or help

[Jee J.Z.]

Hi Christian,


> Maybe I am a little bit lazy when describing my method as "tunnelling".
> Therefore I will go a little bit deeper.
> I know that UDP and TCP protocols are completely different, especially
> the 3-way handshake. But all its steps are TCP packets. Therefore my idea
> is to encapsulate on each side each TCP packet into a UDP packet, send
> this one to the other side, decapsulate the original TCP paket from the
UDP
> packet and inject the TCP packet to the kernel. This way the total TCP
> dialog shall be exchanged as payload of separate UDP packets. UDP
> is necessary, because only UDP can use broadcast addresses.
> (I use this type of address to emulate LAN-broadcast within a mobile
> adhoc network. Therefore I doubt that vtun would help me.)

This sounds to me like that you need two transport layers to do this at the
receivers. Otherwise the encapsulated TCP packets will be forwarded as the
payload of UDP packets to upper layers. The receivers even don't know they
were actually TCP packets, and upper layers will get confused what these
payloads mean. Am I missing something obvious?

Cheers,
Jee

> >
> > > Here is what I wish to do:
> > > For the transmission of IP packets (UDP, ICMP, TCP) between two hosts
> > > I want to send these packets through a UDP tunnel.
> >
> > Tunnelling is a very different matter from converting UDP packets into
TCP
> > packets, and should be eminently feasible.
>
> As I tried to explain, I do NOT want to convert UDP to TCP, I only want to
> transport TCP packets as UDP payload.
>
> I would be glad if you can comment the method described above.
>
> 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
>
>

Re: Need some clarification or help

[Christian Riechmann]

Hello Jee,

On 2004-04-20 22:32:36 +0100, Jee J.Z. wrote:
> Hi Christian,
> 
> 
> > Maybe I am a little bit lazy when describing my method as "tunnelling".
> > Therefore I will go a little bit deeper.
> > I know that UDP and TCP protocols are completely different, especially
> > the 3-way handshake. But all its steps are TCP packets. Therefore my idea
> > is to encapsulate on each side each TCP packet into a UDP packet, send
> > this one to the other side, decapsulate the original TCP paket from the
> > UDP packet and inject the TCP packet to the kernel. This way the total TCP
> > dialog shall be exchanged as payload of separate UDP packets. UDP
> > is necessary, because only UDP can use broadcast addresses.
> > (I use this type of address to emulate LAN-broadcast within a mobile
> > adhoc network. Therefore I doubt that vtun would help me.)
> 
> This sounds to me like that you need two transport layers to do this at the
> receivers. Otherwise the encapsulated TCP packets will be forwarded as the
> payload of UDP packets to upper layers. The receivers even don't know they
> were actually TCP packets, and upper layers will get confused what these
> payloads mean. Am I missing something obvious?

What I have in mind is:
On the receiver the TCP packet, which is part of the payload of the
received ipq-captured UDP packet, shall be decapsulated and then injected
to the kernel (instead of the received UDP packet). Therefore only one
transport layer is envolved.

As I mentioned in my first mail, this method works very well with
encapsulated UDP and ICMP packets, but not with TCP, although a tcpdump
running on the receiver displays the injected IP/TCP packet, but with some
additional bytes at the end. In other words tcpdump seems to display an
IP/TCP packet, which according to the length field of IP shall have only 
64 bytes but really consists of 80 bytes (numbers are only examples).

My assumption is, that these surplus bytes beyond the end, lead to the
problem (maybe a checksum error because of those bytes not belonging to
the TCP packet.) I do not see why during injection the surplus bytes
have not been deleted, although the verdict call is parameterized with
the new length.

Regards
Christian


> 
> Cheers,
> Jee
> 
> > >
> > > > Here is what I wish to do:
> > > > For the transmission of IP packets (UDP, ICMP, TCP) between two hosts
> > > > I want to send these packets through a UDP tunnel.
> > >
> > > Tunnelling is a very different matter from converting UDP packets into
> TCP
> > > packets, and should be eminently feasible.
> >
> > As I tried to explain, I do NOT want to convert UDP to TCP, I only want to
> > transport TCP packets as UDP payload.
> >
> > I would be glad if you can comment the method described above.
> >
> > 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
> >
> >
> 
> 

-- 
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

Re: Need some clarification or help

[Christian Riechmann]

On 2004-04-20 22:07:04 +0100, Antony Stone wrote:

> On Tuesday 20 April 2004 9:51 pm, Christian Riechmann wrote:
> 
> > I know that UDP and TCP protocols are completely different, especially
> > the 3-way handshake. But all its steps are TCP packets. Therefore my idea
> > is to encapsulate on each side each TCP packet into a UDP packet, send
> > this one to the other side, decapsulate the original TCP paket from the UDP
> > packet and inject the TCP packet to the kernel.
> 
> Okay - that sounds to me like a UDP tunnel through which you are sending TCP 
> packets - I agree.

Exact.

> 
> > This way the total TCP dialog shall be exchanged as payload of separate UDP
> > packets. UDP is necessary, because only UDP can use broadcast addresses.
> > (I use this type of address to emulate LAN-broadcast within a mobile
> > adhoc network. Therefore I doubt that vtun would help me.)
> 
> I don't quite understand how this would work.   You say you want to use UDP 
> broadcasts - which suggests to me one sender and many receivers.   TCP cannot 
> work with that, because each receiver is going to want to send 
> acknowledgement packets back to the sender, which will get confused about who 
> is it communicating with.

UDP Broadcast is used to forward packets within the ad hoc network. The
forwarding nodes know whether the received packet has to be forwarded.
Only that node which is the intended receiver of the encapsulated TCP
packet will inject the payload (IP/TCP-packet) to the kernel.
So we have the one-to-one relation. (UDP-Broadcasting is used to a certain
extent as a layer 2 transmission.)
> 
> TCP is basically a one-to-one protocol, and even if you try putting the 
> packets inside UDP packets which can be broadcast to multiple receivers, TCP 
> is still going to want to communicate between one machine at each end.
> 
> Ultimately you have to regard the UDP tunnel as just another route to 
> somewhere, and TCP will use all routes in the same way - to find one machine 
> at the other end.

I think this will not be a problem, because the tunnel is build between
both TCP speaking hosts.

As mentioned earlier, this method works very well if UDP and ICMP packets are
encapsulated. Only a IP/TCP packet (captured and encapsulated at the TCP
sending host and captured, decapsulated and injected at the intended TCPr
receiving host) will not be delivered to the TCP application, although a
tcpdump running on the receiver displays the injected IP/TCP packet,
but with some additional bytes at the end. In other words tcpdump
seems to display an IP/TCP packet, which according to the length field
of IP shall have only 64 bytes but really consists of 80 bytes (numbers
are only examples).

My assumption is, that some surplus bytes beyond the end, lead to the
problem (maybe a checksum error because of those bytes not belonging to
the TCP packet.) I do not see why during injection the surplus bytes
have not been deleted, although the verdict call is parameterized with
the new length.

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

Re: Need some clarification or help

[Jee J.Z.]

Hi Christian,


> > This sounds to me like that you need two transport layers to do this at
the
> > receivers. Otherwise the encapsulated TCP packets will be forwarded as
the
> > payload of UDP packets to upper layers. The receivers even don't know
they
> > were actually TCP packets, and upper layers will get confused what these
> > payloads mean. Am I missing something obvious?
>
> What I have in mind is:
> On the receiver the TCP packet, which is part of the payload of the
> received ipq-captured UDP packet, shall be decapsulated and then injected
> to the kernel (instead of the received UDP packet). Therefore only one
> transport layer is envolved.

Ok, sorry for my misunderstanding. I think this way should work. Just for
curiosity, since multiple receivers will send out their own ACKs for TCP
packets, how does the TCP sender handle these duplicated ACKs?

> As I mentioned in my first mail, this method works very well with
> encapsulated UDP and ICMP packets, but not with TCP, although a tcpdump
> running on the receiver displays the injected IP/TCP packet, but with some
> additional bytes at the end. In other words tcpdump seems to display an
> IP/TCP packet, which according to the length field of IP shall have only
> 64 bytes but really consists of 80 bytes (numbers are only examples).

Does tcpdump show whether the checksum is correct or not? Ethereal does.

> My assumption is, that these surplus bytes beyond the end, lead to the
> problem (maybe a checksum error because of those bytes not belonging to
> the TCP packet.) I do not see why during injection the surplus bytes
> have not been deleted, although the verdict call is parameterized with
> the new length.

Is the length of surplus bytes constant? I tried injecting more bytes
before, and the system does not think these additional bytes as a part of
the original packet; instead, the system thinks it as packet suffix and does
not include it when calculating checksum. However, things might be
different -- just for your information.

Jee

> Regards
> Christian
>
>
> >
> > Cheers,
> > Jee
> >
> > > >
> > > > > Here is what I wish to do:
> > > > > For the transmission of IP packets (UDP, ICMP, TCP) between two
hosts
> > > > > I want to send these packets through a UDP tunnel.
> > > >
> > > > Tunnelling is a very different matter from converting UDP packets
into
> > TCP
> > > > packets, and should be eminently feasible.
> > >
> > > As I tried to explain, I do NOT want to convert UDP to TCP, I only
want to
> > > transport TCP packets as UDP payload.
> > >
> > > I would be glad if you can comment the method described above.
> > >
> > > 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
> > >
> > >
> >
> >
>
> -- 
> 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
>

Re: Need some clarification or help

[Christian Riechmann]

Hello Jee,

On 2004-04-21 16:41:05 +0100, Jee J.Z. wrote:
> Hi Christian,
> 
> 
> > > This sounds to me like that you need two transport layers to do this at the
> > > receivers. Otherwise the encapsulated TCP packets will be forwarded as the
> > > payload of UDP packets to upper layers. The receivers even don't know they
> > > were actually TCP packets, and upper layers will get confused what these
> > > payloads mean. Am I missing something obvious?
> >
> > What I have in mind is:
> > On the receiver the TCP packet, which is part of the payload of the
> > received ipq-captured UDP packet, shall be decapsulated and then injected
> > to the kernel (instead of the received UDP packet). Therefore only one
> > transport layer is envolved.
> 
> Ok, sorry for my misunderstanding. I think this way should work. Just for
> curiosity, since multiple receivers will send out their own ACKs for TCP
> packets, how does the TCP sender handle these duplicated ACKs?

No, no! In case of encapsulated IP/TCP packets there will be only exact one
intended receiving host.

> 
> > As I mentioned in my first mail, this method works very well with
> > encapsulated UDP and ICMP packets, but not with TCP, although a tcpdump
> > running on the receiver displays the injected IP/TCP packet, but with some
> > additional bytes at the end. In other words tcpdump seems to display an
> > IP/TCP packet, which according to the length field of IP shall have only
> > 64 bytes but really consists of 80 bytes (numbers are only examples).
> 
> Does tcpdump show whether the checksum is correct or not? Ethereal does.

Ethereal does not capture the packet including surplus bytes.
tcpdump shows that packet only in case of "tcpdump -x -n -s0 ip" but
that packet is not shown if I use the call "tcpdump -x -n -s0 tcp" or
"tcpdump -x -n -s0 ip \\tcp". Maybe because of checksum error?.
> 
> > My assumption is, that these surplus bytes beyond the end, lead to the
> > problem (maybe a checksum error because of those bytes not belonging to
> > the TCP packet.) I do not see why during injection the surplus bytes
> > have not been deleted, although the verdict call is parameterized with
> > the new length.
> 
> Is the length of surplus bytes constant? I tried injecting more bytes
> before, and the system does not think these additional bytes as a part of
> the original packet; instead, the system thinks it as packet suffix and does
> not include it when calculating checksum. However, things might be
> different -- just for your information.

Yes, the length of surplus bytes is always length_of_captured_packet -
length_of_modified_packet (parameter of the ipq_set_verdict call).

For your info I attach a file including the commented sequence of the
packet flow from sender to receiver.

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

----------------------- Packet flow -----------------------

This is the IPv4/TCP packet captured at the sender:

process_loop: New packet has arrived.  : [21.04 17:21:50]
process_loop: 4510003c 66d14000 40069cc9 80071b06
process_loop: 80071bfd 04120017 6439742f 00000000
process_loop: a0c216d0 09300000 020405b4 0402080a
process_loop: 00a612fe 00000000 01030300

This packet will be encapsulated in userspace and transmitted
via IPv6/UDP-socket as

process_loop: New packet has arrived.  : [21.04 17:21:50]
process_loop: 45000065 00024000 40110373 80071b06
process_loop: 80071bff 040d008c 0051f99f 03010000
process_loop: 00000001 0101003c 4510003c 66d14000
process_loop: 40069cc9 80071b06 80071bfd 04120017
process_loop: 6439742f 00000000 a0c216d0 09300000
process_loop: 020405b4 0402080a 00a612fe 00000000
process_loop: 01030300 fd

On the receiver exactly this packet is captured and
given to the userspace program:

process_loop: New packet has arrived.  : [21.04 17:21:50]
process_loop: 45000065 00024000 40110373 80071b06
process_loop: 80071bff 040d008c 0051f99f 03010000
process_loop: 00000001 0101003c 4510003c 66d14000
process_loop: 40069cc9 80071b06 80071bfd 04120017
process_loop: 6439742f 00000000 a0c216d0 09300000
process_loop: 020405b4 0402080a 00a612fe 00000000
process_loop: 01030300 fd

The userspace program decapsulates the included packet
from the received one to:

process_WM_DATA: length_of_encap_packet = 60
process_loop: MODIFIED Packet: ACCEPTED
process_loop: 4510003c 66d14000 40069cc9 80071b06
process_loop: 80071bfd 04120017 6439742f 00000000
process_loop: a0c216d0 09300000 020405b4 0402080a
process_loop: 00a612fe 00000000 01030300

This packet is injected to the kernel.

A "tcpdump -x -n -s0 ip" running in the receiver host
shows the modified packet as:

17:21:50.855089 128.7.27.6.1042 > 128.7.27.253.23: SWE 1681486895:1681486895(0) win 5840 <mss 1460,sackOK,timestamp 10883838 0,nop,wscale 0> (DF) [tos 0x10]
                         4510 003c 66d1 4000 4006 9cc9 8007 1b06 \
                         8007 1bfd 0412 0017 6439 742f 0000 0000  |
                         a0c2 16d0 0930 0000 0204 05b4 0402 080a  > Original IPv6/TCP packet
                         00a6 12fe 0000 0000 0103 0300           /
                                                       0412 0017 \
                         6439 742f 0000 0000 a0c2 16d0 0930 0000  >  Surplus bytes (Don't know whether they
                         0204 05b4 0402 080a 00a6 12fe 0000 0000  >  can result in a checksum error within TCP)
                         0103 0300 fd                            /

It should be mentioned that, if I use "tcpdump -x -n -s0 ip \\tcp" instead,
tcpdump does not show the former packet. This may lead to the assumption
that this oversized packet may be the reason for the error (because of
checksum error).

Re: Need some clarification or help

[Jee J.Z.]

Hi Christian,

> Hello Jee,
>
> On 2004-04-21 16:41:05 +0100, Jee J.Z. wrote:
> > Hi Christian,
> >
> >
> > > > This sounds to me like that you need two transport layers to do this
at the
> > > > receivers. Otherwise the encapsulated TCP packets will be forwarded
as the
> > > > payload of UDP packets to upper layers. The receivers even don't
know they
> > > > were actually TCP packets, and upper layers will get confused what
these
> > > > payloads mean. Am I missing something obvious?
> > >
> > > What I have in mind is:
> > > On the receiver the TCP packet, which is part of the payload of the
> > > received ipq-captured UDP packet, shall be decapsulated and then
injected
> > > to the kernel (instead of the received UDP packet). Therefore only one
> > > transport layer is envolved.
> >
> > Ok, sorry for my misunderstanding. I think this way should work. Just
for
> > curiosity, since multiple receivers will send out their own ACKs for TCP
> > packets, how does the TCP sender handle these duplicated ACKs?
>
> No, no! In case of encapsulated IP/TCP packets there will be only exact
one
> intended receiving host.

All right. Sorry, I somewhat understand now. I am not familiar with UDP
broadcast in ad hoc networks, but it seems it's really a good idea to do
this using netfilter/libipq!

> >
> > > As I mentioned in my first mail, this method works very well with
> > > encapsulated UDP and ICMP packets, but not with TCP, although a
tcpdump
> > > running on the receiver displays the injected IP/TCP packet, but with
some
> > > additional bytes at the end. In other words tcpdump seems to display
an
> > > IP/TCP packet, which according to the length field of IP shall have
only
> > > 64 bytes but really consists of 80 bytes (numbers are only examples).
> >
> > Does tcpdump show whether the checksum is correct or not? Ethereal does.
>
> Ethereal does not capture the packet including surplus bytes.

Oh, yes. Ethereal only canptures the encapsulated packet. Right?

> tcpdump shows that packet only in case of "tcpdump -x -n -s0 ip" but
> that packet is not shown if I use the call "tcpdump -x -n -s0 tcp" or
> "tcpdump -x -n -s0 ip \\tcp". Maybe because of checksum error?.

Hmmm. Sounds reasonable.

> >
> > > My assumption is, that these surplus bytes beyond the end, lead to the
> > > problem (maybe a checksum error because of those bytes not belonging
to
> > > the TCP packet.) I do not see why during injection the surplus bytes
> > > have not been deleted, although the verdict call is parameterized with
> > > the new length.
> >
> > Is the length of surplus bytes constant? I tried injecting more bytes
> > before, and the system does not think these additional bytes as a part
of
> > the original packet; instead, the system thinks it as packet suffix and
does
> > not include it when calculating checksum. However, things might be
> > different -- just for your information.
>
> Yes, the length of surplus bytes is always length_of_captured_packet -
> length_of_modified_packet (parameter of the ipq_set_verdict call).

Since you know the number of the additional bytes, why not get rid of them
before calling ipq_set_verdict? From your traces, it seems the surplus bytes
are some duplicate part of the original packet. It's strange why they are
here.

> 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.

Regards,
Jee

> 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
>
> ----------------------- Packet flow -----------------------
>
> This is the IPv4/TCP packet captured at the sender:
>
> process_loop: New packet has arrived.  : [21.04 17:21:50]
> process_loop: 4510003c 66d14000 40069cc9 80071b06
> process_loop: 80071bfd 04120017 6439742f 00000000
> process_loop: a0c216d0 09300000 020405b4 0402080a
> process_loop: 00a612fe 00000000 01030300
>
> This packet will be encapsulated in userspace and transmitted
> via IPv6/UDP-socket as
>
> process_loop: New packet has arrived.  : [21.04 17:21:50]
> process_loop: 45000065 00024000 40110373 80071b06
> process_loop: 80071bff 040d008c 0051f99f 03010000
> process_loop: 00000001 0101003c 4510003c 66d14000
> process_loop: 40069cc9 80071b06 80071bfd 04120017
> process_loop: 6439742f 00000000 a0c216d0 09300000
> process_loop: 020405b4 0402080a 00a612fe 00000000
> process_loop: 01030300 fd
>
> On the receiver exactly this packet is captured and
> given to the userspace program:
>
> process_loop: New packet has arrived.  : [21.04 17:21:50]
> process_loop: 45000065 00024000 40110373 80071b06
> process_loop: 80071bff 040d008c 0051f99f 03010000
> process_loop: 00000001 0101003c 4510003c 66d14000
> process_loop: 40069cc9 80071b06 80071bfd 04120017
> process_loop: 6439742f 00000000 a0c216d0 09300000
> process_loop: 020405b4 0402080a 00a612fe 00000000
> process_loop: 01030300 fd
>
> The userspace program decapsulates the included packet
> from the received one to:
>
> process_WM_DATA: length_of_encap_packet = 60
> process_loop: MODIFIED Packet: ACCEPTED
> process_loop: 4510003c 66d14000 40069cc9 80071b06
> process_loop: 80071bfd 04120017 6439742f 00000000
> process_loop: a0c216d0 09300000 020405b4 0402080a
> process_loop: 00a612fe 00000000 01030300
>
> This packet is injected to the kernel.
>
> A "tcpdump -x -n -s0 ip" running in the receiver host
> shows the modified packet as:
>
> 17:21:50.855089 128.7.27.6.1042 > 128.7.27.253.23: SWE
1681486895:1681486895(0) win 5840 <mss 1460,sackOK,timestamp 10883838
0,nop,wscale 0> (DF) [tos 0x10]
>                          4510 003c 66d1 4000 4006 9cc9 8007 1b06 \
>                          8007 1bfd 0412 0017 6439 742f 0000 0000  |
>                          a0c2 16d0 0930 0000 0204 05b4 0402 080a  >
Original IPv6/TCP packet
>                          00a6 12fe 0000 0000 0103 0300           /
>                                                        0412 0017 \
>                          6439 742f 0000 0000 a0c2 16d0 0930 0000  >
Surplus bytes (Don't know whether they
>                          0204 05b4 0402 080a 00a6 12fe 0000 0000  >  can
result in a checksum error within TCP)
>                          0103 0300 fd                            /
>
> It should be mentioned that, if I use "tcpdump -x -n -s0 ip \\tcp"
instead,
> tcpdump does not show the former packet. This may lead to the assumption
> that this oversized packet may be the reason for the error (because of
> checksum error).
>
>
>

Re: Need some clarification or help

[Henrik Nordstrom]

On Tue, 20 Apr 2004, Christian Riechmann wrote:

> is it possible to read - via ipq_read/ipq_get_packet - a UDP packetr
> and after some changes to accept - via ipq_set_verdict with NF_ACCEPT and
> shorter length - it as a TCP packet?

Should be possible.

> Here is what I wish to do:
> For the transmission of IP packets (UDP, ICMP, TCP) between two hosts
> I want to send these packets through a UDP tunnel.

This is best accomplished using a virtual tunnel device for the packet
transformations. This way the packet flow gets natural to netfilter with
no risk of confusing conntrack, and MTU processing etc gets more
natural...  If you want to do the transformations in userspace then use a
tun device.

If you rewrite packets "in the middle of everything" then conntrack will 
get somewaht confused as the packets will look differently depending on 
the direction (conntrack will see forward traffic original, return traffic 
tunneled).  Also, firewalling gets a bit odd. So I would not recommend 
using QUEUE for what you describe.

Regards
Henrik

Re: Need some clarification or help

[root]

Hi Jee,

sorry for my late response.

On Wed, Apr 21, 2004 at 11:17:26PM +0100, Jee J.Z. wrote:

> > > > As I mentioned in my first mail, this method works very well with
> > > > encapsulated UDP and ICMP packets, but not with TCP, although a tcpdump
> > > > running on the receiver displays the injected IP/TCP packet, but with some
> > > > additional bytes at the end. In other words tcpdump seems to display an
> > > > IP/TCP packet, which according to the length field of IP shall have only
> > > > 64 bytes but really consists of 80 bytes (numbers are only examples).
> > >
> > > Does tcpdump show whether the checksum is correct or not? Ethereal does.
> >
> > Ethereal does not capture the packet including surplus bytes.
> 
> Oh, yes. Ethereal only canptures the encapsulated packet. Right?

Yes.

> 
> > tcpdump shows that packet only in case of "tcpdump -x -n -s0 ip" but
> > that packet is not shown if I use the call "tcpdump -x -n -s0 tcp" or
> > "tcpdump -x -n -s0 ip \\tcp". Maybe because of checksum error?.
> 
> Hmmm. Sounds reasonable.
> 
> > >
> > > > My assumption is, that these surplus bytes beyond the end, lead to the
> > > > problem (maybe a checksum error because of those bytes not belonging to
> > > > the TCP packet.) I do not see why during injection the surplus bytes
> > > > have not been deleted, although the verdict call is parameterized with
> > > > the new length.
> > >
> > > Is the length of surplus bytes constant? I tried injecting more bytes
> > > before, and the system does not think these additional bytes as a part of
> > > the original packet; instead, the system thinks it as packet suffix and does
> > > not include it when calculating checksum. However, things might be
> > > different -- just for your information.
> >
> > Yes, the length of surplus bytes is always length_of_captured_packet -
> > length_of_modified_packet (parameter of the ipq_set_verdict call).
> 
> Since you know the number of the additional bytes, why not get rid of them
> before calling ipq_set_verdict? From your traces, it seems the surplus bytes
> are some duplicate part of the original packet. It's strange why they are
> here.

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.

> 
> > 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.

On the other hand, I do not understand why after the verdict call the
packet holds the surplus bytes. Maybe this should be fixed?

Regards

Christian

> > ----------------------- Packet flow -----------------------
> >
> > This is the IPv4/TCP packet captured at the sender:
> >
> > process_loop: New packet has arrived.  : [21.04 17:21:50]
> > process_loop: 4510003c 66d14000 40069cc9 80071b06
> > process_loop: 80071bfd 04120017 6439742f 00000000
> > process_loop: a0c216d0 09300000 020405b4 0402080a
> > process_loop: 00a612fe 00000000 01030300
> >
> > This packet will be encapsulated in userspace and transmitted
> > via IPv6/UDP-socket as
> >
> > process_loop: New packet has arrived.  : [21.04 17:21:50]
> > process_loop: 45000065 00024000 40110373 80071b06
> > process_loop: 80071bff 040d008c 0051f99f 03010000
> > process_loop: 00000001 0101003c 4510003c 66d14000
> > process_loop: 40069cc9 80071b06 80071bfd 04120017
> > process_loop: 6439742f 00000000 a0c216d0 09300000
> > process_loop: 020405b4 0402080a 00a612fe 00000000
> > process_loop: 01030300 fd
> >
> > On the receiver exactly this packet is captured and
> > given to the userspace program:
> >
> > process_loop: New packet has arrived.  : [21.04 17:21:50]
> > process_loop: 45000065 00024000 40110373 80071b06
> > process_loop: 80071bff 040d008c 0051f99f 03010000
> > process_loop: 00000001 0101003c 4510003c 66d14000
> > process_loop: 40069cc9 80071b06 80071bfd 04120017
> > process_loop: 6439742f 00000000 a0c216d0 09300000
> > process_loop: 020405b4 0402080a 00a612fe 00000000
> > process_loop: 01030300 fd
> >
> > The userspace program decapsulates the included packet
> > from the received one to:
> >
> > process_WM_DATA: length_of_encap_packet = 60
> > process_loop: MODIFIED Packet: ACCEPTED
> > process_loop: 4510003c 66d14000 40069cc9 80071b06
> > process_loop: 80071bfd 04120017 6439742f 00000000
> > process_loop: a0c216d0 09300000 020405b4 0402080a
> > process_loop: 00a612fe 00000000 01030300
> >
> > This packet is injected to the kernel.
> >
> > A "tcpdump -x -n -s0 ip" running in the receiver host
> > shows the modified packet as:
> >
> > 17:21:50.855089 128.7.27.6.1042 > 128.7.27.253.23: SWE
> 1681486895:1681486895(0) win 5840 <mss 1460,sackOK,timestamp 10883838
> 0,nop,wscale 0> (DF) [tos 0x10]
> >                          4510 003c 66d1 4000 4006 9cc9 8007 1b06 \
> >                          8007 1bfd 0412 0017 6439 742f 0000 0000  |
> >                          a0c2 16d0 0930 0000 0204 05b4 0402 080a  >
> Original IPv6/TCP packet
> >                          00a6 12fe 0000 0000 0103 0300           /
> >                                                        0412 0017 \
> >                          6439 742f 0000 0000 a0c2 16d0 0930 0000  >
> Surplus bytes (Don't know whether they
> >                          0204 05b4 0402 080a 00a6 12fe 0000 0000  >  can
> result in a checksum error within TCP)
> >                          0103 0300 fd                            /
> >
> > It should be mentioned that, if I use "tcpdump -x -n -s0 ip \\tcp"
> instead,
> > tcpdump does not show the former packet. This may lead to the assumption
> > that this oversized packet may be the reason for the error (because of
> > checksum error).
> >
> >
> >
> 

Re: Need some clarification or help

[Christian Riechmann]

Henrik,

thanks for your answer and hint. But for me there remain
two questions (see below):

On 2004-04-22 02:38:36 +0200, Henrik Nordstrom wrote:
> On Tue, 20 Apr 2004, Christian Riechmann wrote:
> 
> > is it possible to read - via ipq_read/ipq_get_packet - a UDP packetr
> > and after some changes to accept - via ipq_set_verdict with NF_ACCEPT and
> > shorter length - it as a TCP packet?
> 
> Should be possible.

But why exist these surplus bytes beyond the end of the verdicted
IP/TCP packet, which seem to be the reason for a possible checksum 
within the kernel and cause the NOT-delivery of the packet to the
application. I attach a commeted log of the package flow.

> 
> > Here is what I wish to do:
> > For the transmission of IP packets (UDP, ICMP, TCP) between two hosts
> > I want to send these packets through a UDP tunnel.
> 
> This is best accomplished using a virtual tunnel device for the packet
> transformations. This way the packet flow gets natural to netfilter with
> no risk of confusing conntrack, and MTU processing etc gets more
> natural...  If you want to do the transformations in userspace then use a
> tun device.

I do not know whether this proposal is feasable, because I need a 1-to-n
tunnel and the tunnel should allow broadcast addressing. Perhaps you
can help me.

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


------ Commented Log file -------------

This is the IPv4/TCP packet captured at the sender:

process_loop: New packet has arrived.  : [21.04 17:21:50]
process_loop: 4510003c 66d14000 40069cc9 80071b06
process_loop: 80071bfd 04120017 6439742f 00000000
process_loop: a0c216d0 09300000 020405b4 0402080a
process_loop: 00a612fe 00000000 01030300

This packet will be encapsulated in userspace and transmitted
via IPv6/UDP-socket as

process_loop: New packet has arrived.  : [21.04 17:21:50]
process_loop: 45000065 00024000 40110373 80071b06
process_loop: 80071bff 040d008c 0051f99f 03010000
process_loop: 00000001 0101003c 4510003c 66d14000
process_loop: 40069cc9 80071b06 80071bfd 04120017
process_loop: 6439742f 00000000 a0c216d0 09300000
process_loop: 020405b4 0402080a 00a612fe 00000000
process_loop: 01030300 fd

On the receiver exactly this packet is captured and
given to the userspace program:

process_loop: New packet has arrived.  : [21.04 17:21:50]
process_loop: 45000065 00024000 40110373 80071b06
process_loop: 80071bff 040d008c 0051f99f 03010000
process_loop: 00000001 0101003c 4510003c 66d14000
process_loop: 40069cc9 80071b06 80071bfd 04120017
process_loop: 6439742f 00000000 a0c216d0 09300000
process_loop: 020405b4 0402080a 00a612fe 00000000
process_loop: 01030300 fd

The userspace program decapsulates the included packet
from the received one to:

process_WM_DATA: length_of_encap_packet = 60
process_loop: MODIFIED Packet: ACCEPTED
process_loop: 4510003c 66d14000 40069cc9 80071b06
process_loop: 80071bfd 04120017 6439742f 00000000
process_loop: a0c216d0 09300000 020405b4 0402080a
process_loop: 00a612fe 00000000 01030300

This packet is injected to the kernel.

A "tcpdump -x -n -s0 ip" running in the receiver host
shows the modified packet as:

17:21:50.855089 128.7.27.6.1042 > 128.7.27.253.23: SWE 1681486895:1681486895(0) win 5840 <mss 1460,sackOK,timestamp 10883838 0,nop,wscale 0> (DF) [tos 0x10]
                         4510 003c 66d1 4000 4006 9cc9 8007 1b06 \
                         8007 1bfd 0412 0017 6439 742f 0000 0000  |
                         a0c2 16d0 0930 0000 0204 05b4 0402 080a  > Original IPv6/TCP packet
                         00a6 12fe 0000 0000 0103 0300           /
                                                       0412 0017 \
                         6439 742f 0000 0000 a0c2 16d0 0930 0000  >  Surplus bytes (Don't know whether they
                         0204 05b4 0402 080a 00a6 12fe 0000 0000  >  can result in a checksum error within TCP)
                         0103 0300 fd                            /

It should be mentioned that, if I use "tcpdump -x -n -s0 ip \\tcp" instead,
tcpdump does not show the former packet. This may lead to the assumption
that this oversized packet may be the reason for the error (because of
checksum error).

Re: Need some clarification or help

[Jee J.Z.]

Hi root (Christian?),

> Hi Jee,
>
> sorry for my late response.
>
> On Wed, Apr 21, 2004 at 11:17:26PM +0100, Jee J.Z. wrote:
>
> > Since you know the number of the additional bytes, why not get rid of
them
> > before calling ipq_set_verdict? From your traces, it seems the surplus
bytes
> > are some duplicate part of the original packet. It's strange why they
are
> > here.
>
> 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.

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.

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

> >
> > > 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?

> 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.

I am looking forward to your result.

Regards,
Jee

> Regards
>
> Christian
>
> > > ----------------------- Packet flow -----------------------
> > >
> > > This is the IPv4/TCP packet captured at the sender:
> > >
> > > process_loop: New packet has arrived.  : [21.04 17:21:50]
> > > process_loop: 4510003c 66d14000 40069cc9 80071b06
> > > process_loop: 80071bfd 04120017 6439742f 00000000
> > > process_loop: a0c216d0 09300000 020405b4 0402080a
> > > process_loop: 00a612fe 00000000 01030300
> > >
> > > This packet will be encapsulated in userspace and transmitted
> > > via IPv6/UDP-socket as
> > >
> > > process_loop: New packet has arrived.  : [21.04 17:21:50]
> > > process_loop: 45000065 00024000 40110373 80071b06
> > > process_loop: 80071bff 040d008c 0051f99f 03010000
> > > process_loop: 00000001 0101003c 4510003c 66d14000
> > > process_loop: 40069cc9 80071b06 80071bfd 04120017
> > > process_loop: 6439742f 00000000 a0c216d0 09300000
> > > process_loop: 020405b4 0402080a 00a612fe 00000000
> > > process_loop: 01030300 fd
> > >
> > > On the receiver exactly this packet is captured and
> > > given to the userspace program:
> > >
> > > process_loop: New packet has arrived.  : [21.04 17:21:50]
> > > process_loop: 45000065 00024000 40110373 80071b06
> > > process_loop: 80071bff 040d008c 0051f99f 03010000
> > > process_loop: 00000001 0101003c 4510003c 66d14000
> > > process_loop: 40069cc9 80071b06 80071bfd 04120017
> > > process_loop: 6439742f 00000000 a0c216d0 09300000
> > > process_loop: 020405b4 0402080a 00a612fe 00000000
> > > process_loop: 01030300 fd
> > >
> > > The userspace program decapsulates the included packet
> > > from the received one to:
> > >
> > > process_WM_DATA: length_of_encap_packet = 60
> > > process_loop: MODIFIED Packet: ACCEPTED
> > > process_loop: 4510003c 66d14000 40069cc9 80071b06
> > > process_loop: 80071bfd 04120017 6439742f 00000000
> > > process_loop: a0c216d0 09300000 020405b4 0402080a
> > > process_loop: 00a612fe 00000000 01030300
> > >
> > > This packet is injected to the kernel.
> > >
> > > A "tcpdump -x -n -s0 ip" running in the receiver host
> > > shows the modified packet as:
> > >
> > > 17:21:50.855089 128.7.27.6.1042 > 128.7.27.253.23: SWE
> > 1681486895:1681486895(0) win 5840 <mss 1460,sackOK,timestamp 10883838
> > 0,nop,wscale 0> (DF) [tos 0x10]
> > >                          4510 003c 66d1 4000 4006 9cc9 8007 1b06 \
> > >                          8007 1bfd 0412 0017 6439 742f 0000 0000  |
> > >                          a0c2 16d0 0930 0000 0204 05b4 0402 080a  >
> > Original IPv6/TCP packet
> > >                          00a6 12fe 0000 0000 0103 0300           /
> > >                                                        0412 0017 \
> > >                          6439 742f 0000 0000 a0c2 16d0 0930 0000  >
> > Surplus bytes (Don't know whether they
> > >                          0204 05b4 0402 080a 00a6 12fe 0000 0000  >
can
> > result in a checksum error within TCP)
> > >                          0103 0300 fd                            /
> > >
> > > It should be mentioned that, if I use "tcpdump -x -n -s0 ip \\tcp"
> > instead,
> > > tcpdump does not show the former packet. This may lead to the
assumption
> > > that this oversized packet may be the reason for the error (because of
> > > checksum error).
> > >
> > >
> > >
> >
>

Re: Need some clarification or help

[Henrik Nordstrom]

On Thu, 22 Apr 2004, Christian Riechmann wrote:

> I do not know whether this proposal is feasable, because I need a 1-to-n
> tunnel and the tunnel should allow broadcast addressing. Perhaps you
> can help me.

I don't see why tun device can not help you there. It is just another 
method of getting packets in/out of userspace.

It can even be member of a bridge if you like (tap mode), allowing a 
tunneled brigde operation.

Regards
Henrik

Re: Need some clarification or help

[Christian Riechmann]

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

Re: Need some clarification or help

[Christian Riechmann]

Henrik,

On 2004-04-23 09:02:40 +0200, Henrik Nordstrom wrote:

> > I do not know whether this proposal is feasable, because I need a 1-to-n
> > tunnel and the tunnel should allow broadcast addressing. Perhaps you
> > can help me.
> 
> I don't see why tun device can not help you there. It is just another 
> method of getting packets in/out of userspace.
> 
> It can even be member of a bridge if you like (tap mode), allowing a 
> tunneled brigde operation.

Thanks for this advice, I will look at the vtun stuff. Maybe I have
to move the code.

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