Hi,

> >> Actually, it's turning out to be a bit slightly different than I thought.
> >> 
> >> First of all - caveat emptor - I think I'm doing all of this right, but I don't normally operate at the packet level end of things, so i'm not 100% sure of this!
> >> 
> >> So I'm running tcpdump on the freeradius server as it sends the radius packets out, and on the service's server as it receives them, also looking at the output of radiusd -X on the radius IdP to see what it thinks it's about to send, and the output of gss-server on the service to see what is received on the other end of our code.
> >> 
> >> Anything <=247 characters goes through fine. Anything > 247 characters disappears (as we knew).

as Adam has said, you've got to account for the TLV format. however, with VSA, you have the over head
of the Vendor-Specific type.... type 26.

so, from memory, you have the standard  type, length, then vendor ID, then string... but
the string itself is still set up with Type, Length and Attribute specific data (this is
where your SAML goes).

the packet is 255 bytes...then you need to take away all this stuff. 

the first stuff takes 6 bytes off, (T(1), L(1), VID(4)), then the
String itself takes another 2 (Vendor type(1) and vendor length(1)) 

ta-da! 255 bytes becomes 247

> >> In the AVP are always 6 bytes (1a ff 00 00 64 16) at the start (Identifying the attribute?), followed by a VSA of length 249

1a = 26  (VSA)
ff = 255 (fully loaded packet)
00006416 = 25622 (the number of UKERNA vendor)


> >> -> VSA: l=249 t=Unknown-Attribute(132): 3c3f786d6c2076657273696f6e3d27312e302720656e636f…
> >> 
> >> The VSA seems to always have 2 bytes (84 f9) at the start (framing bytes or something?), leaving room for 247 bytes (chars) of content.

84 = 132 (type attribute)
f9 = 149 (length of packet)

have you not got the type 132 attribute in your dictionary file?


alan