decapsulate() error: packet length smaller than encapsulated packet.

[Harmon Nine]

Hello.

I'm getting an error and have no idea why it is occurring. I'm using
the INET framework and sending a large (65536 bytes) packet from one
host through an ethernet connection to a router, then through a ppp
connection to another router, and finally through an ethernet
connection to another host.

The error I'm getting is as follows:

<!> Error in module (IP) NetworkFedTest.ctrl[0].networkLayer.ip
(id=126) at event #603870, t=10.646585139996: (IPDatagram)frame-frag:
decapsulate(): packet length is smaller than encapsulated packet.

I should point out that this seems to occur only during a simulated
network DoS attack in which attack hosts use the same router pathway
to send large packets to a different host on the latter network.

Does anyone know why this is happening and what I can do to fix it?
AFAIK, I'm not doing anything special, just using the INET framework
on top of OMNet4.1.

Thanks.
-- Harmon

[Alfonso Ariza Quintana]

inetmanet has a patch that support the that a fragmented packet could be
decapsulated, you can copy this code from the file
http://github.com/inetmanet/inetmanet/blob/master/src/networklayer/ipv4/IP.cc
the modified code is between the "#ifdef NEWFRAGMENT" macro preprocessor

--------------------------------------------------
From: "Harmon Nine" <harmo...@gmail.com>
Sent: Monday, October 11, 2010 4:41 PM
To: <omn...@googlegroups.com>
Subject: [Omnetpp-l] decapsulate() error: packet length smaller than
encapsulated packet.

> --
> You received this message because you are subscribed to the Google Groups
> "omnetpp" group.
> To post to this group, send email to omn...@googlegroups.com.
> To unsubscribe from this group, send email to
> omnetpp+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/omnetpp?hl=en.
>
>

[Harmon Nine]

Thanks! I'll try it out. :)
-- Harmon

[Harmon Nine]

I commented in "#define NEWFRAGMENT" and rebuilt the inetmanet project.

Unfortunately, the program is still giving the same error.

Is there any way to get omnet to ignore the problem rather than
throwing an exception?

Thanks.
-- Harmon

On Mon, Oct 11, 2010 at 10:29 AM, Alfonso Ariza Quintana
<aari...@hotmail.com> wrote:

[Alfonso Ariza Quintana]

Umm I have now the trace and the problem is other

Error in module (IP) NetworkFedTest.ctrl[0].networkLayer.ip
(id=126) at event #603870, t=10.646585139996: (IPDatagram)frame-frag:
decapsulate(): packet length is smaller than encapsulated packet.

It's necessary to execute the debug and study the problem

If you can send me the scenario I will try to debug, but I can't promise
when I could study the problem, I am a bit busy now organizing the student
laboratories

--------------------------------------------------
From: "Harmon Nine" <harmo...@gmail.com>

Sent: Monday, October 11, 2010 6:15 PM
To: <omn...@googlegroups.com>
Subject: Re: [Omnetpp-l] decapsulate() error: packet length smaller than

[Harmon Nine]

I get it together ASAP. Should I send it as an attachment to this
list, or is there a better place to send it?

In the interim, is there a way to work around this problem, perhaps by
getting omnet to ignore it?

Thanks.
-- Harmon

On Mon, Oct 11, 2010 at 11:33 AM, Alfonso Ariza Quintana

[Alfonso Ariza Quintana]

You can send me directly to my address. I don't recommend the modify the
code for ignore this, you should modify the cPacket core class and usually
this error is the symptoms in other part of the code, possibly a memory lack

--------------------------------------------------
From: "Harmon Nine" <harmo...@gmail.com>

Sent: Monday, October 11, 2010 6:58 PM

[tanktoo]

Hello,

i am using Omnet4.2 with latest inetmanet release. I got the same error if i send a paket via UDP with 75000 byte length. 50000 byte length works.
Anyone has a solution to this error?

With greetings

tanktoo

[tanktoo]

Even tried to include "#define NEWFRAGMENT" in IP.cc file but this doesnt help. The same error occurs afer cleaning and recompiling.

[Alfonso Ariza Quintana]

You are working with DSR, aren’t you?

--
--
Sent from the OMNeT++ mailing list. To configure your membership,
visit http://groups.google.com/group/omnetpp
 
---

You received this message because you are subscribed to the Google Groups "omnetpp" group.

To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[tanktoo]

Hello,

no I am working with "DSDV". Havent tried DSR yet.

[Alfonso Ariza Quintana]

In this case the encapsulate error shouldn’t  produced, this is a bit strange, the problem, usually is with DSR because DSR needs to recapsulate the data.

--

[Alvaro Torres Cortes]

Hello everyone,

I've been trying to reproduce dropping packets due to excessive amount
of traffic.

My configuration is the following,

16 StandardHosts connected via Ethernet100Mb to an EtherSwich.
Every host contains al UDP Basic Burst Application generating
approximately 20 Mbits.
If a host it's selected randomly, there is no problem, since traffic
it's distributed in a uniform way among all the hosts and there is no
reason to drop any packet.

The problem it's when I set all hosts to send packets to the same
destination.
EtherSwich does not drop any packet. Instead of that, it gives me an
error at module EtherMACFullDuplex
"txQueue length exceeds 100 -- this is probably due to a bogus app model
generating excessive traffic (of if this is normal, increase
txQueueLimit!)."

If I increase this limit (txQueueLimit = 0) the simulation runs properly
BUT not even one packet it's dropped, instead of that there is an
infinite buffer at that particular exit port of the switch.

�There is any way of achieving the drop of packets due to excessive
amount of traffic with the Inet-2.0 code?

Thanks in advance.


--
�lvaro Torres Cort�s
PhD Student
Grupo de Redes de Computadores (GRC)
Departamento de Inform�tica de Sistemas y Computadores (DISCA)
Universitat Polit�cnica de Val�ncia (UPV)
UPV, Edificio 1G, Camino de Vera S/N, Valencia 46022 Espa�a
e-mail: atco...@batousay.com
Web: http://www.grc.upv.es

[tanktoo]

Ohm Alvaro what has this to do with my question?
Maybe you should open an extra thread.

Alfonso: So this problem only occurs with DSR? I am sure, that I definitliy use DSDV... and don´t know how this happens.

[Alvaro Torres Cortes]

Hello everyone,
-- excuse me if you receive this message two times but I think that the
first one was sent as a reply to another question --

I've been trying to reproduce dropping packets due to excessive amount
of traffic.

My configuration is the following,

16 StandardHosts connected via Ethernet100Mb to an EtherSwich.
Every host contains al UDP Basic Burst Application generating
approximately 20 Mbits.
If a host it's selected randomly, there is no problem, since traffic
it's distributed in a uniform way among all the hosts and there is no
reason to drop any packet.

The problem it's when I set all hosts to send packets to the same
destination.
EtherSwich does not drop any packet. Instead of that, it gives me an
error at module EtherMACFullDuplex
"txQueue length exceeds 100 -- this is probably due to a bogus app model
generating excessive traffic (of if this is normal, increase
txQueueLimit!)."

If I increase this limit (txQueueLimit = 0) the simulation runs properly
BUT not even one packet it's dropped, instead of that there is an
infinite buffer at that particular exit port of the switch.

There is any way of achieving the drop of packets due to excessive
amount of traffic with the Inet-2.0 code?

Thanks in advance.

--

Alvaro Torres Cortes

PhD Student
Grupo de Redes de Computadores (GRC)

Departamento de Informatica de Sistemas y Computadores (DISCA)
Universitat Politecnica de Valencia (UPV)

[Alfonso Ariza Quintana]

It’s necessary to execute the simulation with the debug and study the problem

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de tanktoo
Enviado el: miércoles, 06 de febrero de 2013 19:29
Para: omn...@googlegroups.com; omn...@googlegroups.com
Asunto: [Omnetpp-l] Re: decapsulate() error: packet length smaller than encapsulated packet.

 

Ohm Alvaro what has this to do with my question?

Maybe you should open an extra thread.

Alfonso: So this problem only occurs with DSR? I am sure, that I definitliy use DSDV... and don´t know how this happens.

--

[tanktoo]

Hm ok. I will do this when i have time. For the moment i will use a workaround with more packets instead of flooding with bigger ones.

[Thorben I.]

Problem still exists if sending messages larger than 65536Byte with UDP socket...

[Alfonso Ariza Quintana]

65536?????

 

I don’t have any dude that you will have problems. The length field in IP packets is 16 bits, these size is bigger than the maximum IP packet payload.

 

 

De: omn...@googlegroups.com [mailto:omn...@googlegroups.com] En nombre de Thorben I.
Enviado el: lunes, 24 de febrero de 2014 14:49
Para: omn...@googlegroups.com
Asunto: [Omnetpp-l] Re: decapsulate() error: packet length smaller than encapsulated packet.

 

Problem still exists if sending messages larger than 65536Byte with UDP socket...

--

[Thorben I.]

Sorry, missed something, stupid idea^^