Arduino Yun Wifi Connectivity Problem after System Update

Hi,

Good day.
Just want to know if somebody encounters this problem on the attached picture?
Wherein after applying the latest Arduino Yun's update, it can connect to the router but cannot be pinged.
It registers to the wifi client but cannot access the Arduino page for configuration.
I tried repeating the upgrade procedure to reset the Yun's original State but failed.
Thanks..

Best Regards,
Leo

@lpestanas,

how do you know you are connected to the router?
how do you know the YUN is connected to the router?

what is your IP?
what is the IP of your YUN?

Jesse

Hi Ipestanas

I can see in your captured image the address 192.168.1.102 with MAC address 90:a2...
You ping 192.168.20.102.
Are you sure, you ping the correct address?

Hi Sir,

Sorry for posting the wrong picture.
I tried to ping 192.168.1.102 and still "destination host unreacheable.
The same with my android phone, it is connected to this USB router modem.
The phone is able to get internet connection even if it cannot be pinged using the laptop.
The security is WEP.

I know that these devices are connected due to their corresponding MAC addresses.

I saw on the console "deauthenticating wlan0 due to "WEP/TKIP" policy on the YunSerial Terminal program when I "hard reset" the Yun.

We have 3 wifi servers on our side one of them is working fine.
The only difference that I can see is the wifi encryption which is WPA/WPA2 on the said working wifi server. Does the WEP encryption has something to do with the connectivity? Is there a way for it like my phone to connect both on WEP and WPA/WPA2 as long as I know the passkey paraphrase?

Thanks,
Leo

@lpestanas,

how do you know you are connected to the router?

I think you answered this question.

how do you know the YUN is connected to the router?

You did not answer this question, but you implied that it was connected - because you saw it disconnect.

what is your IP?
what is the IP of your YUN?

You did not answer these questions. What are the IPs of the machines involved?
Your response is adding noise, not answering questions. We can help, please answer questions.

Jesse

Hi Sir,

Sorry for making noise if you said so. I'll try to be more cautious next time.
I'm just a new user and not aware of any rules for talking.

The IP address for the Yun in the picture named "Capture1" just today is 192.168.1.100.
The IP address for the laptop in the picture named "Capture1" just today is 192.168.1.102.
I assure (2) wifi clients are connected. No other workstation is allowed to enter.
Before it used to work on that wifi server, but now I don't know what happened.

The file named "Capture4" is this message returned in YunSerialTerminal.
Wherein I use WPA/WPA2-PSK, AES+TKIP wifi encryption on the usb wifi modem/router.

The file named "Capture5" is this message returned in YunSerialTerminal.
Wherein I use WPA-PSK, TKIP wifi encryption on the usb wifi modem/router.

From end to end as of now,
I assure on the Yun, laptop and usb wifi router is having the same encryption.
And only (2) of them are connected.

Thanks and Best Regards,
Leo

lpestanas:
Hi Sir,

Sorry for making noise if you said so. I'll try to be more cautious next time.
I'm just a new user and not aware of any rules for talking.

The IP address for the Yun in the picture named "Capture1" just today is 192.168.1.100.
The IP address for the laptop in the picture named "Capture1" just today is 192.168.1.102.
I assure (2) wifi clients are connected. No other workstation is allowed to enter.
Before it used to work on that wifi server, but now I don't know what happened.

The file named "Capture4" is this message returned in YunSerialTerminal.
Wherein I use WPA/WPA2-PSK, AES+TKIP wifi encryption on the usb wifi modem/router.

The file named "Capture5" is this message returned in YunSerialTerminal.
Wherein I use WPA-PSK, TKIP wifi encryption on the usb wifi modem/router.

From end to end as of now,
I assure on the Yun, laptop and usb wifi router is having the same encryption.
And only (2) of them are connected.

Thanks and Best Regards,
Leo

@lpestanas,

there are NO rules. I am just trying to make sense your problem.

There are several problems and I do not have enough information.

  1. you have 3 machines on your wifi.
  • 192.168.1.100 - appears to be your Yun
  • 192.168.1.101 - You did not mention a third machine (maybe your router), but your ping (Capture1.JPG) says that this machine (101 - also called LEO-WIN7H) is answering for you Yun (100). This is one problem.
  • 192.168.1.102 - you say is the IP to your laptop. I will take your word for it.
  1. those 3 machines have MAC addresses
  • 90:a2:da:f6:07:6c - appears to be your Yun (according to Capture1.JPG)
  • 14:cc:20:24:cc:0d - appears to be LEO-WIN7H (according to Capture1.JPG). This is a problem.
  • 78:f5:fd:3a:71:98 - appears to be another router (according to Capture4.JPG & Capture5.JPG)

Do it all again. This time DO NOT post images. Copy the text into your clipboard, then paste - there is more information in those logs that can help. Also, please use markup (see image below).

ALSO, this may or may NOT be related to your upgrade.

TIA
Jesse

arduino_markup.png

Hi Sir,

Ok, Thanks for the idea.
At least this is not related to Yun's system upgrade which I feared that I "bricked" it.
Anyway, I still manage to have two wifi servers to connect to it that works no problem.
I'll soon post my findings if anything will change again on that usb router/modem connectivity.
Just strange that the past weeks it run successfully and now cannot even "Ping" even the handphone from the laptop on the same router/network.

Thanks and Best Regards,
Leo

lpestanas:
The IP address for the Yun in the picture named "Capture1" just today is 192.168.1.100.
The IP address for the laptop in the picture named "Capture1" just today is 192.168.1.102.
I assure (2) wifi clients are connected. No other workstation is allowed to enter.
Before it used to work on that wifi server, but now I don't know what happened.

This doesn't make any sense.

If your laptop is 192.168.1.102, why is it not on the list of connected clients? And if no other workstations are allowed to enter, what is "LEO-WIN7H" at 192.168.1.101?

And what's most interesting is that when trying to ping 192.168.1.100, you get a "destination host unreachable" message. That's usually reserved for situations where there is no possible network route to the destination address, often because there isn't a gateway address defined. But in this case, it's the SAME network, and no gateway or router should be necessary. You shouldn't be getting the unreachable message unless there is something quite wrong with the network configuration on that computer (not necessarily the Yun.)

And why is it 192.168.1.101 that is reporting the unreachable route? Another node should not be involved with pinging something on the same network. It sure sounds like "LEO-WIN7H" at 192.168.1.101 is actually the computer in the screenshot running the ping command, and that something is not quite right with the network configuration on that computer.

Could you please run a couple commands and copy/paste the text output (in code tags like Jesse said, not as a screen capture image)? First, run the [color=blue]ping [/color]command like you have so we can see the output, and then run the [color=blue]ipconfig /all[/color]command so we can see how the network is configured on that computer.

Good Day,

As requested, I performed what you want me to check. Please see below:

C:\Users\user>ping 192.168.1.101 ----->>> Arduino Yun

Pinging 192.168.1.101 with 32 bytes of data:
Reply from 192.168.1.100: Destination host unreachable.
Reply from 192.168.1.100: Destination host unreachable.
Reply from 192.168.1.100: Destination host unreachable.
Reply from 192.168.1.100: Destination host unreachable.

Ping statistics for 192.168.1.101:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

C:\Users\user>ping 192.168.1.100 ------>>> LEO-WIN7H IP address (Laptop)

Pinging 192.168.1.100 with 32 bytes of data:
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128
Reply from 192.168.1.100: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.100:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

C:\Users\user>

==========================================================================

C:\Users\user>ipconfig/all

Windows IP Configuration

Host Name . . . . . . . . . . . . : LEO-WIN7H
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No

Wireless LAN adapter Wireless Network Connection 4:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft Virtual WiFi Miniport Adapter #2
Physical Address. . . . . . . . . : 14-CC-20-24-CC-0C
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Wireless Network Connection 3:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : TP-LINK Wireless USB Adapter
Physical Address. . . . . . . . . : 14-CC-20-24-CC-0D
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::7165:4a7b:4c6b:c894%24(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.1.100(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Monday, March 30, 2015 8:52:45 AM
Lease Expires . . . . . . . . . . : Tuesday, March 31, 2015 8:52:36 AM
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DHCPv6 IAID . . . . . . . . . . . : 722783264
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1A-C4-5E-C8-20-1A-06-DF-56-77
DNS Servers . . . . . . . . . . . : 192.168.1.1
192.168.1.1
NetBIOS over Tcpip. . . . . . . . : Enabled

Ethernet adapter Bluetooth Network Connection:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Bluetooth Device (Personal Area Network)
Physical Address. . . . . . . . . : 28-E3-47-38-97-13
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Wireless Network Connection:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Qualcomm Atheros AR956x Wireless Network Adapter
Physical Address. . . . . . . . . : 28-E3-47-38-3A-1B
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet
Physical Address. . . . . . . . . : 20-1A-06-DF-56-77
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : fe80::34fc:8979:8ecc:4602%11(Preferred)
IPv4 Address. . . . . . . . . . . : 192.168.20.157(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.20.50
DHCPv6 IAID . . . . . . . . . . . : 287316486
DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-1A-C4-5E-C8-20-1A-06-DF-56-77
DNS Servers . . . . . . . . . . . : 192.168.20.1
202.188.1.5
NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{04ED784C-9987-4E42-83AE-DCEA3B5CA1D7}:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.{54ACFE9C-0834-4A38-BF61-6F6D71832C4E}:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter Local Area Connection* 12:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
IPv6 Address. . . . . . . . . . . : 2001:0:9d38:90d7:862:8b32:4854:5e35(Preferred)
Link-local IPv6 Address . . . . . : fe80::862:8b32:4854:5e35%25(Preferred)
Default Gateway . . . . . . . . . : ::
NetBIOS over Tcpip. . . . . . . . : Disabled

Tunnel adapter isatap.{7B065047-BBDB-4934-9819-71A60CAE9399}:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #4
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.{87B11EB8-CA8C-485F-B675-B8421E8F6F47}:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #5
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.{3E350B42-6554-45B9-9018-30D40451F14A}:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Microsoft ISATAP Adapter #6
Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes

C:\Users\user>

--->>>it is really strange to get the response "destination host unreachable".
Much better if we can see "request time out".
While on the other server it works fine and the good thing it used to work on this usb wifi modem/router.

My laptop can be "Pinged" while the Yun cannot when attached to this network.
I took note of the MAC addresses and it is the same. I performed a lot of reset to bring it back to default state but failed.

Thanks and Best Regards,
Leo

Please upload the YunSerialTerminal sketch, open the serial monitor and then press the YUN_RST button.

Post here the output of the serial monitor.

There is some incorrect or misleading information in this thread. I'm not quite just just what's going on, but I believe it is a configuration problem in the wireless access point, and NOT a problem with the Yun.

Summarizing a few key lines from the ifconfig output:

Windows IP Configuration
   Host Name . . . . . . . . . . . . : LEO-WIN7H

Wireless LAN adapter Wireless Network Connection 3:
   Description . . . . . . . . . . . : TP-LINK Wireless USB Adapter
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.1.100(Preferred)

First off, from the Host Name entry, it is clear the LEO-WIN7H is indeed the laptop, and it has address 192.168.1.100 and not 192.168.1.102 as previously indicated. Now, this address may have changed over time, so it may have been different in the past, but the laptop was previously reported to be at a different address from LEO-WIN7H which is not correct and caused some of the confusion.

With the laptop at 192.168.1.100, that explains why it is possible to successfully ping 192.168.1.100: it is the local network adapter, and should always be reachable. But why is the other address "not reachable"?

I suspect it has to do with the "(Preferred)" annotation after the address. I've got a pretty good grasp of how the networking and addressing protocols work, but not so much on how Windows implements them, and I know nothing about how Widows 7 configures them. The "Preferred" annotation was apparently introduced by Windows 7 and it seems to indicate that there was a problem getting an address over DHCP, and since Autoconfiguration is enabled it went ahead and tried to "guess" at an address, and the "Preferred" annotation means that it confirmed that no other nodes are using that address at the moment. While it was confirmed to be unique just now, that doesn't mean it's actually a valid address, nor does it mean that another node might not come along later and claim that address (either because it was statically defined, or perhaps the DHCP server started working and handed it out not knowing that some other node assigned it itself.)

The gist of it is that this does not appear to be a valid addressed handed out by a DHCP server. I assume the WiFi access point is supposed to be the DHCP server? It does not appear to be configured properly, or is not working properly.

I wrote several long explanations of what might be going on, but I think it was all just noise so I deleted them.

Before spending too much more time pondering possibilities, I think we need more information.

  • What is acting as the WiFi access point?
  • What is displaying the addresses in the screen shots? Is this the access point or another router?
  • What is the Ethernet network configuration?
  • What other routers are there?
  • Is there any connection between the Ethernet and the WiFi?

There appears to be something wonky with the network configuration. A clear diagram of how everything relates to each other would go a long way toward figuring it out. It's clear from the previous posts that Leo is not clear on this, so it may take some effort to figure out.

Hi Sir,

If the problem is not with the Yun and let us focus on other. All I can remember is I perform the update twice to get the default password "arduino" and that's the start of the whole thing of connectivity problem. Since that I am still exploring the effect if I'm going to apply the update again.

Before spending too much more time pondering possibilities, I think we need more information.
What is acting as the WiFi access point?
--->> This is a USB wifi/router Modem with sim card. Huawei E355 is the model.
What is displaying the addresses in the screen shots? Is this the access point or another router?
--->> The one displaying is the GUI of the USB router/modem. Where you can administer everything on that network, including the viewing of MAC addresses and ip assignments of corresponding wifi clients.
What is the Ethernet network configuration?
--->> For the USB router/modem. It is a DHCP and by default have encryption of WEP.
I also tried WPA/WPA2 with encryption of TKIP/AES.
What other routers are there?
--->> The other (2) wifi routers are the company infrastructure.
No problems seen on connecting to these routers/servers.
Is there any connection between the Ethernet and the WiFi?
--->No, the network they are connected are different. The Gigabit Ethernet is connected to the company local network while the wifi is connected to this router modem. I tried also removing the LAN cable and have both wifi work alone on my last thread.

My concern now is, If I'm going to deploy my project and encounter such configuration of wifi like this.
That the local IT can show to me that local computers can Ping and point to my project which is network defective wise. The last thing I never attempted is to reset this router to default. Where I cannot see an export button to save the original config before resetting.

Thanks,
Leo

Hi Sir,

The YUN Serial terminal message is attached for common reference. Before, I used to highlight the last message on it which is related connecting to this USB wifi router/modem. "AP Bug" and followed by some messages related to wifi. This YUN Serial terminal message is not present on the other (2) wifi router.

I'll try tomorrow to bind the MAC Addresses inside the USB Modem/router to wifi clients and see the effect. If this will remove the (preferred) message on the network configuration.

Thanks to all having sometime to give some opinions and possible solutions.
I hope you don't get mad at me, just a newbie exploring linux and Yun.

Thanks and Best Regards,
Leo

Yun Reset Message.txt (27.1 KB)

lpestanas:
What is acting as the WiFi access point?
--->> This is a USB wifi/router Modem with sim card. Huawei E355 is the model.

OK, I think I've got it. You have a laptop connected to the corporate Ethernet. You also have a USB cellular modem plugged into the laptop, and that is acting as an access point. The GUI in your screenshots is the web interface to that USB cellular/WiFi hotspot. The laptop is "connected" to that hotspot over USB, and the Yun is connected to that USB modem using WiFi.

Is that correct?

That the local IT can show to me that local computers can Ping and point to my project which is network defective wise.

I don't know what you're saying here. Are you saying that other computers can reach your Yun, just not your laptop? If so, that might be due to the USB connection to the modem, and the Ethernet connection, and it doesn't know which one to use?

lpestanas:
"AP Bug" and followed by some messages related to wifi.

I don't see this message on my Yuns either. This may be a key piece of information.

A Google search of those error messages show that it is (or was) a known problem connecting to certain access points. It looks like there was a fix for it, which made it into some Linux kernals, but it would appear that it hasn't made it into OpenWRT.

Someone with a good knowledge of Linux and OpenWRT is going to have to address this, it's not within my area of expertise.

I wish I had a solution for you, but at least I think we're closing in on the issue.

Hi Sir,

OK, I think I've got it. You have a laptop connected to the corporate Ethernet. You also have a USB cellular modem plugged into the laptop, and that is acting as an access point. The GUI in your screenshots is the web interface to that USB cellular/WiFi hotspot. The laptop is "connected" to that hotspot over USB, and the Yun is connected to that USB modem using WiFi.
Is that correct?

  • Yes, That is correct.

Quote
That the local IT can show to me that local computers can Ping and point to my project which is network defective wise.
I don't know what you're saying here. Are you saying that other computers can reach your Yun, just not your laptop? If so, that might be due to the USB connection to the modem, and the Ethernet connection, and it doesn't know which one to use?

The laptop can ping the USB modem/router but the Yun in anyway cannot be reached and posting "destination host unreachable" even if you see the MAC address connected as client inside the USB Modem/Router GUI. And it suddenly acts like that, but before no problem.

Quote from: lpestanas on Today at 10:19 am
"AP Bug" and followed by some messages related to wifi.
I don't see this message on my Yuns either. This may be a key piece of information.
A Google search of those error messages show that it is (or was) a known problem connecting to certain access points. It looks like there was a fix for it, which made it into some Linux kernals, but it would appear that it hasn't made it into OpenWRT.
Someone with a good knowledge of Linux and OpenWRT is going to have to address this, it's not within my area of expertise.
I wish I had a solution for you, but at least I think we're closing in on the issue.

Yes, I think this is a wifi connectivity bug for this version of linux.
If I were to ship my product to my customers, I cannot mandate the corporate IT of that company to change their wifi settings or access point settings. My product should adapt to their existing corporate networking policies like a normal Smart Phone that sees an access point and enter the wifi key/paraphrase. I want to address this concern to the Openwrt or linux experts, problems may arise in the future because of connectivity compatibility issues such as this. I want to promote this Yun as my primary platform of embedded development due to its powerful capability. Sooner we will or somebody can find the answer.

Thanks and Best Regards,
Leo

lpestanas:
Hi Sir,

SHAPSHIFTER OK, I think I've got it. You have a laptop connected to the corporate Ethernet. You also have a USB cellular modem plugged into the laptop, and that is acting as an access point. The GUI in your screenshots is the web interface to that USB cellular/WiFi hotspot. The laptop is "connected" to that hotspot over USB, and the Yun is connected to that USB modem using WiFi.
Is that correct?

  • Yes, That is correct.

Quote
That the local IT can show to me that local computers can Ping and point to my project which is network defective wise.
SHAPESHIFTER I don't know what you're saying here. Are you saying that other computers can reach your Yun, just not your laptop? If so, that might be due to the USB connection to the modem, and the Ethernet connection, and it doesn't know which one to use?

The laptop can ping the USB modem/router but the Yun in anyway cannot be reached and posting "destination host unreachable" even if you see the MAC address connected as client inside the USB Modem/Router GUI. And it suddenly acts like that, but before no problem.

Quote from: lpestanas on Today at 10:19 am
"AP Bug" and followed by some messages related to wifi.
::::SNIP::::
[/quote]
Okay, this is just as I expect.
1) lpestanas, you were not giving us the entire story.
2) lpestanas, you are reaching for straws. Your assumptions are all wrong.
3) lpestanas, your network skill are lacking. You don't know enough about IP networks. You are making bad assumptions.
4) Just because several computer have similar IP numbers does NOT mean they are talking to each other. This is a rare case, but this is being caused by your networks setup - which is NOT standard.
5) Coming up with theories (and not understanding them) -- has us answering wrong questions AND is not allowing us to get to problem.
6) "destination host unreachable" means the machine that is responding IS the gateway to the route that gets you to the TARGET
In English, this means that the machine answering with "destination host unreachable" (call it 192.168.1.100) thinks that it knows where the YUN is (call it 192.168.1.101). So your laptop (192.168.1.102) sends a message to 192.168.1.100, and it (the AP or Gateway) says I know where it is, I cannot see it from where I am. You don't see that message, but the industry standard "destination host unreachable"
HOW TO FIX THIS:
1) I highly recommend you take a course in IP networking. WE CANNOT give you that education in a forum setting.
2) Get your IT people to help you.
3) All device that want to talk to the YUN must connect to the same AP.
4) The "routing metric" for the AP must be greater than one (1). This means it must assign all outbound traffic that metric or you will get "destination host unreachable".
5) There MUST be a route from the the laptop to the AP to the YUN or you will get "destination host unreachable". (This is likely your problem.)
If I am correct, you will need to use traceroute(1) to find your problem. Find it on your laptop (it maybe called troute - or similar) or download a copy.
Lastly, I worked at a robotics company. I was in charge of customer support for WIFI. There is NO solution for this problem. Customer using HOTSPOTs in there company environment are on there own. We did not support that problem. All companies that sell IP networks have similar policies.
I hope this is clear. If not, please ask more questions.
Jesse

Hi Sir Jesse,

I hope you don't get me wrong.

  1. lpestanas, you were not giving us the entire story.

So little by little, we are not going to jump to deeper analysis which will mislead if basic steps are not executed. If you were to isolate defective machine, you will consult a manual and do it step by step from the basic to complicated.

For example along the thread, some say "upload the YunSerial Reset message and let us see", and I did upload it to satisfy the information he need. It doesnt inquire to me to give a finding about "tracert", which you bring up just now. Which I did as a part of basic network connection isolation but nobody ask the question if I do so.

2) lpestanas, you are reaching for straws. Your assumptions are all wrong.

Data is different from opinion. A newbie like me more likely I call the statement to be an opinion.
Why? I follow the basic step of Ping and tracert to perform basic network isolation. Why do I "Ping"? I need to see if my network packet can reach my destination. Why do I "tracert"? to see if the node is able to complete hoping from the workstation back and forth to the router.

I do not trust assumptions as well, that's why I need to try solutions one by one and see what's the best

3) lpestanas, your network skill are lacking. You don't know enough about IP networks. You are making bad assumptions.

If you think it is lacking. A newbie like me will do the basic steps of network isolation such as Ping and tracert. Is there any more basic than these methods to see if you are connected on the network?

  1. Just because several computer have similar IP numbers does NOT mean they are talking to each other. This is a rare case, but this is being caused by your networks setup - which is NOT standard.

If the USB modem/router doesnt follow the IEEE 802.11 and DHCP protocol standard.
I believe this device will not be on the market for some reason because of the international standard.
My mistake if I did forget or alter some settings on this USB modem/router to make it not working with Yun. That's why I'm gathering some expert opinions to execute it one by one if I did alter or miss something.

To summarize my concern from the start and start isolating the problem from here:

  • I cannot Ping anymore the Yun after the update twice. If somebody see this problem before?
    Before it used to work on the same USB Modem/Router without any problem.

  • I can see the Yun and the laptop inside the USB Modem/Router GUI
    indicating that they are on the same router, the same default configuration of DHCP.
    The view as before it used to work.

  • After the update twice, this "AP Bug" message appeared on the Yun Serial terminal.
    Tried (2) new Arduino Yun out of the box. Still the same after reformatting the SD card
    using the YunDiskExpander sketch.

HOW TO FIX THIS:
1) I highly recommend you take a course in IP networking. WE CANNOT give you that education in a forum setting.

To get the status of connectivity along the same network, router and configured as DHCP by default. You can use the methods "Ping" and "tracert". Those methods you should check if you lost connection on the network. The question now, why in the normal corporate infrastructure on the (2)new Yun connects seamlessly while before the USB modem/router without altering the DHCP configutation aside form wifi encryption/password started not to work.

And inside the Arduino IDE 1.6.1, connecting to the (2)working wifi server instantly the wifi port will appear with the assigned IP address on the Serial Port. While on the USB modem/router cannot anymore.

2) Get your IT people to help you.

We are too lucky if they will assist us if we will encounter this problem. All they would do is to assign the IP Address they will give to the Yun.

3) All device that want to talk to the YUN must connect to the same AP.

I can view and assign the wifi clients to this USB Modem/Router.
Aside from the IP Address it is in tandem with the MAC Address.

4) The "routing metric" for the AP must be greater than one (1). This means it must assign all outbound traffic that metric or you will get "destination host unreachable".

Where can I see this "Routing Metric"? Does the laptop can Ping this USB Router/Modem has the AP routing metric greater than (1)? Where can I see it?
Why the new Yun out of the Box still cannot connect to this USB Router Modem by after updating and on the (2) routers can connect seamlessly?

5) There MUST be a route from the the laptop to the AP to the YUN or you will get "destination host unreachable". (This is likely your problem.).
If I am correct, you will need to use traceroute(1) to find your problem. Find it on your laptop (it maybe called troute - or similar) or download a copy.

Yes, when you tracert the IP of the Yun from the laptop assigned by the USB modem/router.
It does not complete the hops. it stated "destination host unreachable".
While the laptop can complete the hop.

So, if we are on the same router same subnet
On the other (2) network. from laptop to Yun hop is completed.
I can connect also thru SSH using the (2)network without any problem.

Lastly, I worked at a robotics company. I was in charge of customer support for WIFI. There is NO solution for this problem. Customer using HOTSPOTs in there company environment are on there own. We did not support that problem. All companies that sell IP networks have similar policies.

The concern is I want my system to be adaptable to any kind of DHCP.
Specially related to this weird USB modem/router phenomena.
We never know if I can encounter some of this kind of network config in the future deployment.
All we can do is to adapt to that network configuration and have the Yun connected with good network functionality.

Yes, If they will use DHCP configuration. The config of the USB modem/router policy is the same.
The router will assign the IP Address available along the subnet.
It will only differ the port forwarding, VLAN and additional security feature.
Regardless whether you are running linux or windows environment,
they will follow the same OSI layer, IEEE standard and TCP/IP and DHCP Protocol for all these platforms.

Thanks and Best Regards,
Leo

ShapeShifter:
A Google search of those error messages show that it is (or was) a known problem connecting to certain access points. It looks like there was a fix for it, which made it into some Linux kernals, but it would appear that it hasn't made it into OpenWRT.

Someone with a good knowledge of Linux and OpenWRT is going to have to address this, it's not within my area of expertise.

I wish I had a solution for you, but at least I think we're closing in on the issue.

So, has anyone else tried searching for these error messages that appear at the end of his boot up text?

[   55.570000] wlan0: AP bug: HT capability missing from AssocResp
[   55.580000] wlan0: AP bug: HT operation missing from AssocResp

There does appear to be a bug in at least some Linux versions that can't handle the packets sent from some access points. It looks like it has been fixed in some Linux versions, but apparently not in the current OpenWRT-Yun version?

Perhaps the bug was not present in the earlier version that was on the board from the factory, but is now present in the newer upgrade version that was subsequently loaded by the OP? I'm not familiar enough with the Linux bug-tracking process to know when or how it was fixed, and when that fix might be applied to OpenWRT (if ever) and when it may make it into OpenWRT-Yun (if ever.)

Maybe someone who is more versed in the Linux world could look into it rather than berating the OP for the initial incomplete information? :wink:

Yes, this is not a "standard" network setup, but using a combined cellular/WiFi hotspot is far from being an unusual situation (in fact, such a setup is my only Internet connection for the whole house.) The big difference is that the hotspot in this case plugs into a USB port to get its power from the host computer - not the end of the world.

The WiFi standards are complex, and there is a lot of variation in the way it is implemented by various AP vendors. I've had great luck so far with the Yun, but I have run into problems with other brands of embedded WiFi client hardware where it will connect to some hotspots and not others. This is far from a unique occurrence (and the pages that can be found from a quick search show that the OP is not the only one seeing those particular error messages in his log.)

@ShapeShifter,
I'm frustrated for other reason beyond this individual thread. I'm dropping out and ignoring the thread. From what I can see, the Hotspot is issuing conflicting messages to the laptop and the YUN. That is, the Hotspot is saying, "Hey I'm authoritative. I can give you an answer." In conflict is the in-house AP - it is also saying, "Hey I'm authoritative. I can give you an answer."

So the race condition is resolved when each responses to the closest (or fastest) responding AP. Where the YUN connects is based on multiple factors beyond reasonable control.

Factors include:

  1. is there other radio noise in the room (ie. mircowave oven, wifi printer, drill press, etc.)?
  2. is the weather humid?
  3. how many wifi connections are active?
  4. what is the nature of the wifi traffic in the room?
  5. is the 220V AC line under floor properly grounded?

Trace all these issues and more and you'll get a solution. I'm not going that route, thats' why I'm dropping.

TO Trace the problem, in a concise fashion, remove the YUN from the environment and add components - one at a time.

@lpestanas,
as you can see, I dropping this. I wish you the best in life.

Jesse