Re: Wireshark fails to display UDP packets

[PRASANTH RAJAGOPAL <prasanthris () gmail com>]

Actually the frame filter would fail me any expression on anything
concerned with displaying UDP. I then went on to try TCP and ICMP, and
all had exactly same results. I realized there must be some mistakes
in packet. I also saw that the flags relating to fragmentaion and the
offset etc were not really getting programmed correctly in packETH.

Further Googling helped me find this more stable (yet wonderful)
packet generator:
http://code.google.com/p/ostinato/

Now I can generate any type of packet and all of them are correctly
dissected by Wireshark.

Thanks for the inputs.


On 12/2/11, Chris Maynard <Chris.Maynard () gtech com> wrote:
> Stephen Fisher <steve@...> writes:
>
> > > What I don't understand is, why wireshark does not detect UDP
> > > protocol, when IP protocol has already detected it. Maybe that will
> > > help me see what mistake is done in the frame.
> >
> > I suspect it is because the packets are fragmented IP.  Do you have the
> > "reassemble fragmented IPv4 datagrams" preference enabled under the IPv4
> > protocol preferences?
>
> Even if the "reassemble fragmented IPv4 datagrams" preference is enabled,
> the IP
> fragments will still only be displayed as you see in the picture.  The only
> difference would be with the last fragment - if all fragments were present
> (and
> not ignored, as it looks like might be the case from the attached screen
> shot) -
> then Wireshark could reassemble the IP fragments into a complete UDP packet.
>
> If you don't want to bother looking at the unreassembled IP fragments, you
> can
> use a display filter to exclude them, such as with something like,
> "!(ip.flags.mf == 1)" or simply "udp".
>
> Of course if you don't have "reassemble fragmented IPv4 datagrams" enabled,
> then
> "udp" will match the first fragment instead of the last/reassembed one, so
> you
> might decide to change your filter a bit to something like, "ip.frag_offset
> ==
> 0" or again, you could just use "udp".  Note that you won't see the entire
> reassembled packet in this case, but the UDP header will be dissected as
> well as
> however many bytes of UDP payload data were present in the first fragment.
>
> - Chris
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>
> mailto:wireshark-users-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe