[ifmapdev] Problems publishing to omapd.

24 views
Skip to first unread message

Terry Simons

unread,
May 16, 2010, 12:58:38 AM5/16/10
to ifmapdev
Hi,

I'm trying to publish some canned DHCP messages to omapd, but I'm
running into some issues.

The particular error I'm getting appears to be caused by omapd being
particularly strict on the ip-mac message type, or that it doesn't
realize that the message type is a single value metadata type message.

I'm using example #2 (section 8.3) on page 63 of IF-MAP v1.1r5.

The only thing I've changed is that I've added a proper session-id.

Here are the steps I take:

1) start omapd
2) request a new session
3) attempt to publish ip-mac sample (from spec) with proper session-id

Here is the error I get back from the server after sending the ip-mac
message:

ClientParser::~ClientParser:
Server::socketReady: Successful SSL handshake with peer: "127.0.0.1"
Server::socketReady: Client authorized because
ifmap_require_client_certificates is false, for peer: "127.0.0.1"
reading session-id
MapSessions::validateSessionId: Using session-id in client request:
"050f4a7b2cfce64dd248ac31bb62f3b1"
MapSessions::validateSessionId: Got session-id:
"050f4a7b2cfce64dd248ac31bb62f3b1" and publisherId: "127.0.0.1"
ClientHandler::readMetadata: Error: metadata element has no
"cardinality" attribute: "ip-mac"
Server::readClient: Got request type: "Publish" and IF-MAP version:
"IFMAPv11"
Server::readClient: Client Error: "InvalidMetadata"
Server::processPublish: Error in publish: "InvalidMetadata"
Server::sendMapResponse: Sent reply to client:
"<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/
envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:ifmap="http://
www.trustedcomputinggroup.org/2006/IFMAP/1">
<SOAP-ENV:Header>
<ifmap:session-id>050f4a7b2cfce64dd248ac31bb62f3b1</ifmap:session-
id>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ifmap:response>
<errorResult errorCode="InvalidMetadata"/>
</ifmap:response>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
"

ClientParser::~ClientParser:

I realize this isn't the place for troubleshooting omapd, but I would
like to better understand some of the notes in the specification
regarding the cardinality option.

I am assuming since cardinality is never specified in the example ip-
mac message, that it isn't required and the specification states that
cardinality is by default singleValue (which is what ip-mac is). So I
really think this is a bug in omapd but there are some comments in the
specification that make it a little bit unclear to me.

Quoting from page 17:

"The MAP Server determines whether a metadata type is single-valued or
multi-valued using the cardinality attribute of an instance received
in a publish request. If the MAP Server has access to the schema that
defines the metadata, the MAP Server can tell whether a metadata type
is single-valued or multi-valued even if the cardinality attribute is
missing by getting the default value from the schema. If the MAP
Server does not have the schema that defines the metadata and the
cardinality attribute is missing, the MAP Server MUST treat the
metadata type as multi-valued. For this reason, MAP Clients using
vendor-specific metadata types MUST include cardinality attributes in
instances of single-valued metadata types.

If a MAP Client sends a publish request in which the cardinality
attribute differs from the cardinality in the schema, the MAP Server
MUST respond with an InvalidMetadata error. "

Why does the specification narrowly call out vendor-specific metadata
types as ones that must include cardinality attributes in instances of
single-valued metadata types?

It seems to me that this ought to be the case even for standard
metadata types... and that the examples in the specification ought to
address this so that those examples will work in broken
implementations that don't include defaults from any schemas.

One could argue that broken implementations are broken, and as such
they do not deserve special treatment, but I don't see any difference
between a "standard" and "vendor-specific" metadata type in the case
where the schema isn't loaded, so it doesn't make sense to single-out
vendor-specific types in this case.

And I would also point out that having it explicitly spelled out in
the specification isn't a bad thing. I'm not an XML wizard, so it
isn't even clear to me by looking at the specification what I need to
do to fix my message so that it *will* work. How do I add a
cardinality=singleValue attribute to my message? Is it simply an
attribute on the meta:ip-mac tag like this: <meta:ip-mac
cardinality="singleValue"/>?

Andrew Benton

unread,
May 16, 2010, 3:44:22 AM5/16/10
to ifma...@googlegroups.com
david mattes may be able to add more to this, but i'll take a stab.

first, you are correct in your last statement. i.e., to get it to
"just work" all you should need is a cardinality="singleValue"
attribute on your ip-mac element.

as to the vendor-specific and standard metadata cardinality issue,
presumably the standard metadata schema is always loaded in any map
server implementation, since it's public. so default cardinalities can
always be looked up for the standard metadata. other schemas though
might not be loaded, so you need to be a little more specific.

david, any reason omapd isn't using default cardinality for ip-mac?

amb

Sarab Mattes

unread,
May 16, 2010, 2:44:44 PM5/16/10
to ifma...@googlegroups.com
Hi Terry and Andrew,

Currently, omapd does not load _any_ metadata schemas to validate against - that is definitely a desired feature.  Furthermore, omapd requires the cardinality attribute to be present, or it issues an error.  That is a bug!  As you point out, if the MAP server has no access to the metadata schema, the metadata cardinality MUST treat the metadata as multiValue.  I'll fix that momentarily.

Thanks!
Sarab D. Mattes

Sarab Mattes

unread,
May 16, 2010, 3:56:35 PM5/16/10
to ifma...@googlegroups.com
Fixed in omapd revision 68.

Terry, feel free to submit issues on omapd google code page!
Reply all
Reply to author
Forward
0 new messages