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