[tahoe-dev] [tahoe-lafs] #690: STRING token too large: 252>200

[tahoe-lafs]

#690: STRING token too large: 252>200
--------------------------+-------------------------------------------------
 Reporter:  adigeo        |           Owner:  warner  
     Type:  defect        |          Status:  assigned
 Priority:  major         |       Milestone:  1.4.1   
Component:  code-network  |         Version:  1.4.1   
 Keywords:                |   Launchpad_bug:          
--------------------------+-------------------------------------------------
Changes (by warner):

  * owner:  => warner
  * status:  new => assigned


Comment:

 Curious.. I'm guessing you're running into an unexpected constraint on the
 size of a FURL that can be transmitted over the wire, in this case inside
 the
 "subscribe" message that is sent to the Introducer. This message contains
 information to let the Introducer know where it ought to send future
 announcements: the FURL of the subscriber. This FURL is ephemeral (it
 changes
 each time the client node is restarted), but has the same general form as
 other, more-persistent ones.

 Do those systems have a lot of IP addresses? Maybe lots of multihoming, or
 Xen/VMware/etc virtual interfaces that don't actually talk to the outside
 world? Or some IPv6 interfaces?

 Look at $NODEDIR/private/control.furl , as it will have the same tubid and
 "location hints" string as the ephemeral subscriber FURL. It will be in
 the
 form {{{pb://TUBID@HOST:PORT,HOST:PORT/SWISSNUM}}}, where both TUBID and
 SWISSNUM are base32 characters. The {{{HOST:PORT}}} sections (of which
 there
 can be an arbitrary number) are just dotted-quad IP address and decimal
 port
 number.

 The node will try to figure out a good set of connection hints to put in
 this
 string at startup. The code that does this might conceivably put multiple
 addresses in there if it thinks that you have multiple externally-visible
 network interfaces. (also note that different variants of this code are
 run
 on different operating systems, so the behavior I get out of linux might
 not
 be the same as someone running solaris, etc).

 The code inside Foolscap that handles FURLs passed this way (i.e. as
 serialized Referenceables) has a built-in limit of 200 bytes on the length
 of
 the FURL string. This is enough for 129 bytes of location hints, or 5
 maximal-length hint strings (i.e. "255.255.255.255:12345,"). If the
 auto-detect-local-IP-addresses code decided to put 6 or more hints in that
 string, you'd exceed the 200-byte limit.

 The workaround for this would be to manually set the advertised location
 hint
 in your tahoe.cfg file. Specifically, choose one or two address+port
 locations where the client can be reached, then in the [node] section,
 store
 the hints in the tub.location field:

  [node]
  tub.location = 10.0.0.8:12345,255.255.255.255:12345

 Once you do that, the client will publish FURLs with the tub.location
 hints
 instead of trying to figure them out on its own, which should hopefully
 avoid
 the length limitation.

 (note that, for the purposes of the Introducer-to-subscriber announcement
 messages, the hints are not strictly necessary: those announcements will
 be
 sent back over the same TCP connection that the client used to subscribe
 in
 the first place. But if you want your storage server to be reachable by
 other
 clients, you'll need to provide a working location here).

 Please let us know if this works, and what was causing the hint string to
 be
 too long (or if I'm wrong and it's some other problem altogether).

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/690#comment:2>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid