Re: Problem with capturing DHCP Faillover (DHCPFO) Protocol and the OMAPI Protocol

[Jürgen Dietl <juergen.dietl () googlemail com>]

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 () xs4all nl>

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