[Rack] robot IP address still not working
jake at spaz.org
Tue May 1 15:27:18 PDT 2012
i will personally escort the vyatta box off the premises if you can
describe it well enough for me to locate it. you might as well start
setting up the bsd router now because i will eventually find and
do-ocratically remove the vyatta thing.
port forwarding won't bbe enough for several reasons. one is that this is
a development machine, meaning that the whole POINT is for users to be
able to open any kind of connection they want, any time, in either
direction. NOT spend all night trying to get port forwarding to work on a
new service. and i dont want to have to create a new login on pony for
every user of the robot. it is its own machine on the internet. its
connections should not be mediated by another machine like pony.
ben doesn't even respond to this issue anymore. please just go ahead and
reinstate the bsd router.
On Tue, 1 May 2012, Jonathan Lassoff wrote:
> On Tue, May 1, 2012 at 1:08 PM, Jake <jake at spaz.org> wrote:
>> It has been over six months since the robot wheelchair had an IP address.
>> Work on the robot has basically stopped since then, because there is no
>> way to get into it from the outside world.
>> I do not have the ability to do anything about this myself, because the
>> network at noisebridge is way too complicated for me to be able to do
>> anything close to what I would have to do. The most I can handle is
>> setting up a router at a house with DSL, and turning on DMZ mode.
>> Otherwise I would have done it myself by now.
>> Since the robot can no longer be accessed from the outside world, all
>> development on it has stopped. It is frozen in time since the moment its
>> umbilicus to the world was ruthlessly cut.
>> It is almost too late to get it to a point where it's worth taking to
>> maker faire. It doesn't do anything new. A lot of scripts are not
>> working and need massaging to get them back into order.
>> People have told me to use SSH port forwarding, but then they were unable
>> to get it to work themselves, and there's extra lag because it has to pass
>> through another machine. It's not a solution at all. Even if I could do
>> it I wouldn't be able to explain it to the developers whose work I solicit
>> on the robot. It's not an option.
>> I don't understand why it's impossible to give the robot an IP address.
> I really want this to work again, too. I really do.
> It's because of this Vyatta router that SuperQ put in. Its
> configuration for NAT services doesn't actually seem to apply and do
> what it should. It's Linux, but the management portion of things is
> closed source. So, I've hit a point where I can't dive any deeper into
> the problem.
> There's an additional problem wherein the translated address needed to
> get assigned to the external interface, but sshd is bound to *,
> meaning the SSH daemon of the router was picking up, instead of NATing
> stuff to MC Hawking.
> I could "fix" the underlying configuration on the Linux kernel, but
> that takes the configuration out of the Vyatta CLI, which I perceive
> as the only real advantage to the Vyatta box.
> I for one, would like to bring back the OpenBSD router. It worked well
> for years, and was replaced because ....well, I don't really recall
> why SuperQ had such zeal for a Linux router. I think the general
> impression was that OpenBSD was "different" and users didn't want to
> have to learn it to get stuff done.
> Perhaps those that like the Vyatta box can speak as to why it's a win
> for Noisebridge.
> Jake -- based on our previous discussion, it sounds like all you
> wanted was inbound (externally-initiated, landing on the robot as the
> destination) SSH. If that's all, then we can easily forward you a port
> from Pony or Minotaur. Connections to that port would just get
> transparently masqueraded into MC Hawking instead.
> Are there any special protocols you want to have talking into and out
> of the robot?
> My suggestion about tunneling still stands, though. Adding a daemon on
> MC Hawking that transparent forward robot-hosted IP services into a
> Internet-connected machine would be the best all-around solution.
> That way, it can even be driven around, via cellular or foreign
> Internet-connected WiFi networks and still be spoken to in the same
> I don't know where others have fallen in getting this to happen, but
> I'd like to see it work. I'm willing to help develop whatever tooling
> is necessary.
More information about the Rack