Wireshark-users: Re: [Wireshark-users] Problem with capturing DHCP Faillover (DHCPFO) Protocol an

From: Jürgen Dietl <juergen.dietl@xxxxxxxxxxxxxx>
Date: Tue, 8 Feb 2011 09:30:02 +0100
Hello again Jaap,

if I dont want to be jobless tomorrow posting a capture here is not that easy. But I will try to explain better:

When I do a trace of dhcpfo, i get for example the follwoing output:

No.     Time        Absolute Time   Source                Destination           New Column Protocol Info                                                            New Column
     49 52.520664   10:40:59.573315 xx.xxx.xx.xxx         xx.xxx.xx.xxx         efs        DHCPFO   Binding acknowledge xid: 37dcd                                  10:40:59.573315

Frame 49: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: HewlettP_77:c8:a0 (00:17:a4:77:c8:a0), Dst: HewlettP_77:c8:98 (00:17:a4:77:c8:98)
Internet Protocol, Src: xxxxxxxxxxxxxxx, Dst: xxxxxxxxxxxxxxxxxxx)
Transmission Control Protocol, Src Port: 64538 (64538), Dst Port: efs (520), Seq: 730, Ack: 1362, Len: 20
DHCP Failover
    Message length: 20
    Message Type: Binding acknowledge (4)
    Payload Offset: 12
    Time: Feb  2, 2011 10:40:59 Westeuropäische Normalzeit
    Xid: 0x00037dcd
    Payload Data
        DHCP Style Option, assigned-IP-address (2), 172.22.112.136

If this happens I can see the header information as dhcpfo will all the parameters. But I have a lot of packets that also have the dhcpfo port (which I changed to 520) but look like this:

No.     Time        Absolute Time   Source                Destination           New Column Protocol Info                                                            New Column
    102 143.389124  10:42:30.441775 xx.xxx.xxx.xxx         xx.xxx.xx.xxx         efs        TCP      11026 > efs [ACK] Seq=5528 Ack=2134 Win=8760 Len=0              10:42:30.441775

Frame 102: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Ethernet II, Src: HewlettP_77:c8:98 (00:17:a4:77:c8:98), Dst: HewlettP_77:c8:a0 (00:17:a4:77:c8:a0)
Internet Protocol, Src: xxxxxxxxxxxxxxxxxxxxxxxxx, Dst: xxxxxxxxxxxxxxxxxxxxxxxxx
Transmission Control Protocol, Src Port: 11026 (11026), Dst Port: efs (520), Seq: 5528, Ack: 2134, Len: 0

In this case even if its port 52ß the protocol is not dhcpfo but efs. About 50 % of the packets are this efs. If this happens I only have a tcp header with messed up data.

So why dont I see all the port 520 packets as dhcpfo?

In special I look for

* recorver-wait
* recover-done

thanx a lot for your help,
cheers,
Juergen



2011/2/7 Jaap Keuter <jaap.keuter@xxxxxxxxx>
Hi,

In order to look at what happens with the DHCP failover it might be helpful to attach the capture file.

As for the OMAPI dissector, yes it's in there (I've put it in), and no you can't change its port through a preference setting. It's fixed at 7911.

Thanks,
Jaap


On 02/07/2011 02:55 PM, Jürgen Dietl wrote:
Hello,

I did a capture on the DHCP-Server. Because our DHCP runs on port 520 i
changed this in the preferences of the dhcpfo protocol.

I can decode the following message types.

3  = Binding Update
4  = Binding Acknowledge
5  = Connect
6  = Connect Acknowledge
7  = Update Request All
8  = Update Done
10 = State

When I now make a display filter with !dhcpfo.type==5 and
!dhcpfo.type==4 .....

so that I filter out all this types I still have messages on port 520
that can only be seen as "efs tcp dst port 520" with a source port not
well known (greater than 1024).

I am looking for the recovery-wait and. recovery-done etc. I assume that
the missing packets must be there. But wireshark do not decode this
packet with a DHCP Failover Header. Instead all the information is in
data in the TCP Header which then is difficult to decode.

Is there a way to decode also the rest?

I am also looking for the name of the OMAPI Protocol for changing the
port in preferences. It is in the supported protocol list as "OMAPI ISC
Object Management API" but I cant find any of these words.

Thanx a lot,
cheers,
Juergen

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
           mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe