[zeromq-dev] PGM subscriber assert failure

[Advait Alai]

>
> 1. make sure you've done a set_sockopt ZMQ_SUBSCRIBE to "" or something
> else, that's an easy mistake! 2. Use wireshark or similar to make sure the
> packets are arriving at the other machine. If not, then investigate your
> router - no idea on the config I'm afraid.
>

I've set the ZMQ_SUBSCRIBE "" already.

I looked at wireshark; the epgm subscriber seems to be receiving packets,
but I cannot see the data payload, which is why it probably does not print
anything. With tcp, the raw data is clearly visible, so the socket.recv()
call works fine.

At the publisher, the bind call is: serv_socket.bind("epgm://10.0.66.1;
225.0.0.1:5555")
At the subscriber, the connect call is: client_socket.connect ("epgm://
10.0.22.1;225.0.0.1:5555")

=============================================
With TCP, I can clearly see the data (at the end of the paste)
=============================================

 Transmission Control Protocol, Src Port: personal-agent (5555), Dst Port:
33749 (33749), Seq: 25, Ack: 1, Len: 24
    Source port: personal-agent (5555)
    Destination port: 33749 (33749)
    Sequence number: 25    (relative sequence number)
    [Next sequence number: 49    (relative sequence number)]
    Acknowledgement number: 1    (relative ack number)
    Header length: 32 bytes
    Flags: 0x18 (PSH, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 1... = Push: Set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 91
    Checksum: 0xfdef [correct]
        [Good Checksum: True]
        [Bad Checksum: False]
    Options: (12 bytes)
        NOP
        NOP
        Timestamps: TSval 32384152, TSecr 32383907
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 2]
        [The RTT to ACK the segment was: 1.000596000 seconds]
Data (24 bytes)

0000  17 00 6e 6f 64 65 35 2c 31 33 2c 31 33 30 33 33   ..node5,13,13033
0010  36 35 33 31 34 2e 31 38                           65314.18
    Data: 17006E6F6465352C31332C313330333336353331342E3138

===========================
With EPGM, there is no data visible
===========================

Transmission Control Protocol, Src Port: personal-agent (5555), Dst Port:
34125 (34125), Seq: 1, Ack: 1, Len: 0
    Source port: personal-agent (5555)
    Destination port: 34125 (34125)
    Sequence number: 1    (relative sequence number)
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x14 (RST, ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgment: Set
        .... 0... = Push: Not set
        .... .1.. = Reset: Set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 0
    Checksum: 0x505b [correct]
        [Good Checksum: True]
        [Bad Checksum: False]
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 77]
        [The RTT to ACK the segment was: 0.038680000 seconds]

================================================

Is there some added encapsulation of multicast packets that prevents the
data from being read by wireshark?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110421/81127a59/attachment.htm>