[list] lan connection not found

[corymickelson]

I've run t2 wifi {credentials} and got a response of WIFI enabled. WIFI {connection info}, but when I run t2 update it can not find the lan connection.

[finnp]

This is happening for me as well on OS X. I suspect it being my wifi. device.local is available though and all the other network stuff works. Just not t2 update and t2 root.

Of course I was running t2 provision before.

[johnnyman727]

@finnp so you are able to ping device.local but not the IP address of the device?

[finnp]

@johnnyman727 I am able to ping both. It's just that t2 list doesn't find the LAN connection.

[albatrocity]

Same as @finnp. I'm able to t2 run successfully but update and list don't seem to be aware of LAN. run could be pushing code over USB, I can't tell.

[albatrocity]

Running t2 wifi --l shows me two networks with the same SSID, one of which I'm connected to with Tessel. I don't doubt there are duplicate network names where I am, so this may just be a fringe case or a non-issue. Could be nice to somehow choose between the two.

[finnp]

I was digging into this a bit. It seems like the mdns-js module can't find the device. I used a more low level package multicast-dns to test if this is an issue with mdns-js. However also this module didn't work. I do suspect now that it might be some kind of issue with node maybe. Tomorrow I'll do some tests with my chromecast to see if I can detect it.

Here are some logs:

$ dns-sd -B _tessel._tcp .
Browsing for _tessel._tcp
DATE: ---Wed 13 Apr 2016---
 2:31:54.029  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
 2:31:54.030  Add        2   5 local.               _tessel._tcp.        jake

Tessel had the ip address 192.168.1.125.

$ DEBUG=mdns:* t2 list --lan
INFO Searching for nearby Tessels...
  mdns:lib:networking interface +0ms en0 192.168.1.110
  mdns:lib:networking creating socket for +5ms en0
  mdns:lib:networking bindToAddress +8ms en0
  mdns:lib:networking sending to +5ms { address: '192.168.1.110', family: 'IPv4', port: 59400 }
  mdns:lib:networking created buffer with length +26ms 36
  mdns:outbound message +0ms 000001000001000000000000075f74657373656c045f746370056c6f63616c00000c0001
  mdns:lib:networking 192.168.1.110 sent 36 bytes with err:0 +2ms
  mdns:lib:networking stopping +5s
  mdns:lib:networking socket closed +1ms { address: '192.168.1.110', family: 'IPv4', port: 59400 }
WARN No Tessels Found.

[johnnyman727]

@finnp thanks so much for looking into this. You may want to check out some comments from the mdns-js author: mdns-js/node-mdns-js#47. If you have time, could you look into whether you have any other Bonjour services running?

[finnp]

So I sudo lsof +M -i4 | grep mdns and there was only mDNSResponder listening for mdns queries.

So I disabled mDNSResponder with

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponderHelper.plist

But that didn't help.

[huseyinkozan]

Was same here on Ubuntu 14.04. t2 list had showed USB but not LAN.

I disabled the firewall, then it works. The docs must mention about ports. (Also, I opened 5353 but had not worked.)

[HipsterBrown]

While digging into this issue, my Tessel showed up on LAN in the beginning but stopped showing up at some point. However, when I lookup the _tessel._tcp service directly, using dns-sd, it was available:

Nicks-MacBook-Pro:johnny-five hipsterbrown$ t2 list
INFO Searching for nearby Tessels...
    USB tessel-router
Nicks-MacBook-Pro:johnny-five hipsterbrown$ dns-sd -L tessel-router _tessel._tcp local
Lookup tessel-router._tessel._tcp.local
DATE: ---Fri 15 Apr 2016---
 0:28:48.924  ...STARTING...
 0:28:48.925  tessel-router._tessel._tcp.local. can be reached at tessel-router.local.:22 (interface 4)

That _tessel._tcp service doesn't show during a general browse using dns-sd:

Nicks-MacBook-Pro:johnny-five hipsterbrown$ dns-sd -B
Browsing for _http._tcp
DATE: ---Fri 15 Apr 2016---
 0:32:52.637  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
 0:32:52.638  Add        2   4 local.               _http._tcp.          Deskjet 3050A J611 series [3FF41C]

It's all quite odd.

I'm going to read through the mdns-js docs & source a bit to see how the discovery systems differ.

[johnnyman727]

@HipsterBrown do you still have this issue even after resetting mDNSResponder? (sudo killall -HUP mDNSResponder)

[finnp]

@HipsterBrown Running dns-sd -B only browses for _http._tcp. If you run dns-sd -B _services._dns-sd._udp you should be able to see it.

[finnp]

I finally figures out the issue! (for me at least) I really should have thought of it earlier. I have the Mac OS X Firewall turned on, that blocks all Bonjour connections.

So I went to "Security & Privacy" and unchecked "Block all incoming connections". When I ran "t2 list" then, I was asked if I want to allow node to accept connections. Here's a screenshot:

Sorry for not thinking about this earlier... and thanks for your help!

[johnnyman727]

@finnp This is fantastic! Nice work!

@HipsterBrown, I think the best way to 'resolve' this is to get up better documentation on how to fix this on OSX (using these wonderful tips) and Linux and then link to that doc on the start experience.

[johnnyman727]

@finnp out of curiosity, what version of OSX are you running?

[finnp]

@johnnyman727 Yosemite 10.10.5. The firewall was turned off by default by the way, I enabled it at some point.

[johnnyman727]

Good to know, thanks! I wasn't sure if I just happened to have turned mine off at some point and assumed it was off by default for everyone.

[finnp]

I also thought about how to test if a firewall is used.

Here's a rough idea. If trying to send a message to itself is not working, it's likely that there is a firewall issue (or some other interference):

var dgram = require('dgram')
var socket = dgram.createSocket('udp4')

socket.on('message', function (message, remote) {
  console.log('received', remote.address + ':' + remote.port + ' - ' + message)
})

socket.on('listening', function () {
  var address = socket.address()
  console.log('UDP Client listening on ' + address.address + ':' + address.port)
  socket.setBroadcast(true)
  socket.setMulticastLoopback(true)
  socket.setMulticastTTL(128)
  socket.addMembership('224.1.1.1')
  var message = new Buffer('test')
  socket.send(message, 0, message.length, address.port, '224.1.1.1')
  console.log('Sent test.')
})

socket.bind(function () {})

[johnnyman727]

@finnp this would be a great addition to the CLI. We could run it asynchronously with the mDNS discovery and print a warning if an error is thrown. Have you confirmed this test works?

[huseyinkozan]

Can't we use firewall while developing ?

[johnnyman727]

Yes, but you won't be able to use mDNS discovery. We have an open issue to add an --ip flag you can specify that actual address of your Tessel but it's not implemented yet

[mattsoftware]

Whoah, we are not seriously going to suggest turning off the firewall? Why
does dns-sd show responses if its just the firewall thats the problem. And
why does connecting everything to a mobile phone hotspot not require
disabling firewall. I will be investigating my t2 further this weekend
after an intense week at work. Hopefully there is a way without disabling
firewall cause that is NOT an option for me!

The --ip flag would be a great edition, but I am sure we can work out how
to get bonjour working without disabling the firewall, it is an apple
sponsored protocol to start with and thats how apple tv, airplay, itunes,
etc works.

Matt.

On Fri, Apr 15, 2016 at 10:33 PM, Jon notifications@github.com wrote:

Yes, but you won't be able to use mDNS discovery. We have an open issue to
add an --ip flag you can specify that actual address of your Tessel but
it's not implemented yet

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#650 (comment)

[huseyinkozan]

Ubuntu filrewall workaround:

• Find IP address of the Tessel.
• Reserve that IP at the DHCP server or configure the Tessel for using static IP.
• Allow all incoming requests by adding a rule like : sudo ufw allow from <IP>.

[Injac]

Simple and good workaround, if the Tessel always has the same IP-Address. If you have more than one Tessel, you have to add that entry as well, using ufw. For a more "general" approach, one could simply allow all traffic from the local subnet, like this:

sudo ufw allow from 192.168.177.0/24

[mbrevda]

In my case, disabling the firewall did NOT cause the tessel to show up (os x)

[Injac]

Have you connected the Tessel via LAN or WLAN? Does it show up on your router with an assigned IP-Address?

[mbrevda]

WLAN, yes I see it in the DHCP lease list

[Injac]

A short list that helps me most of the time when dealing with IoT devices:

• Are you able to ping it?
• Have you tried to access the device via SSH (trying alternative access, if the ping is working) ?
• Do you have any kind of additional security/anti-virus based software running on your system that could block access to the Tessel?
• Maybe your router prevents access to the Tessel? Settings?

[mbrevda]

I can ping, I can ssh directly (although t2 root doesnt work). I tried disabling my firewall, didnt help. mDns is showing the device:

# dns-sd -B _tessel._tcp .
Browsing for _tessel._tcp
DATE: ---Tue 26 Apr 2016---
 0:24:49.911  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
 0:24:54.569  Add        2   4 local.               _tessel._tcp.        doorman

[Injac]

It looks very similar to this issue, maybe it is an IPV6 problem as well:
Unable to t2 root/update
Here is the pull request:
Ipv6 link local fix

I have configured my router not to use IPV6 at all. Had no further issues so far.

[mbrevda]

After a reboot, I got the firewall prompt and now I can see the device listed under LAN properly. Thanks!

[Injac]

Nice :) Glad it finally worked out for you.

[johnnyman727]

I'm going to close this issue as there doesn't seem to be anything we can do with the CLI to resolve it - it seems stem for network configurations. However, if you do experience this problem and have data points to add, please continue to comment with your information.