Operating System: Linux
Platform: Other

Attachment test4.zip has been added with description: Log output + wireshark trace

Could you please retest?
There was merged a fix for bug responsible for killing threads during handshake.
BUG-995

I've just tried distributions-base-0.1.2-20140525.222643-753-osgipackage.zip. Can't see any nodes in the GUI.

Fyi Bhavish - PACKET IN towards Controller has buffer id and no data is not supported by the implementation.

Well it appears that Opendaylight is not correctly setting a rule on the switches. That is, flow action is send to controller but 0 bytes. Also, I can't see ODL creating any flow rules to punt LLDP towards controller either. Not sure how it figures out that this is an LLDP packet.

What's the expected behaviour?

Folks,

Are we setting a rule in the switches to specifically punt the LLDP packets to the controller? This will make our LLDP discovery more robust. I don't think we are doing this. So action 1 - install an explicit LLDP flow to punt LLDP packets to the controller.

Also it is likely that we are expecting the whole unbuffered packet during the packet-ins - rather than partial packets. In this case it makes sense to explicitly configure the switch to send the full unbuffered packets to the controller (to make the controller operation more predictable & not dependent on the switch defaults). From the spec:

From 6.1.2 Asynchronous:

"If the packet is buffered, the number of bytes of the original packet to include in the packet-in can be configured. By default, it is 128 bytes. For packet-in generated by an output action in a flow entries or group bucket, it can be specified individually in the output action itself (see 7.2.5), for other packet-in it can be configured in the switch configuration (see 7.3.2)."

The output action has the following:

/* Action structure for OFPAT_OUTPUT, which sends packets out ’port’.

• When the ’port’ is the OFPP_CONTROLLER, ’max_len’ indicates the max
• number of bytes to send. A ’max_len’ of zero means no bytes of the
• packet should be sent. A ’max_len’ of OFPCML_NO_BUFFER means that
• the packet is not buffered and the complete packet is to be sent to
• the controller. */
  struct ofp_action_output {
  uint16_t type;
  uint16_t len;
  uint32_t port;
  uint16_t max_len;
  uint8_t pad[6];
  /* OFPAT_OUTPUT. */
  /* Length is 16. */
  /* Output port. */
  /* Max length to send to controller. */
  /* Pad to 64 bits. */
  };

From:

7.3.2 Switch Configuration:

/* Switch configuration. */
struct ofp_switch_config {
struct ofp_header header;
uint16_t flags;
uint16_t miss_send_len;
/* Bitmap of OFPC_* flags. */
/* Max bytes of packet that datapath
should send to the controller. See
ofp_controller_max_len for valid values.
*/
};

"The miss_send_len field defines the number of bytes of each packet sent to the controller by the OpenFlow pipeline when not using an output action to the OFPP_CONTROLLER logical port, for example sending packets with invalid TTL if this message reason is enabled. If this field equals 0, the switch must send zero bytes of the packet in the ofp_packet_in message. If the value is set to OFPCML_NO_BUFFER the complete packet must be included in the message, and should not be buffered."

So action 2:
1) make sure the default switch configuration for packet-in miss_send_len is OFPCML_NO_BUFFER
2) make sure the LLDP flow output action has max_len as OFPCML_NO_BUFFER.

We can make that change - and then have Bhavish try it again.

This was split into https://bugs.opendaylight.org/show_bug.cgi?id=1544 and https://bugs.opendaylight.org/show_bug.cgi?id=1545. Both closed - so closing this.