Hi Experts
I have flashed my tx1 board and it works with some of samples.
I have also run wifi-config-check and it also ran succesfully.
But my browser chromium does not work at all. I get the error message:
This site cant be reached. https://www.google.com is unreachable.
Any hints?
Thanks,
Sojohan
I don’t remember the details, but at one point my chromium was not working because it needed be added to some password system. On the other hand, what does your Jetson get an address when it runs “host google.com” (it’ll probably show many)? Does it show an address for “host mail.google.com”, and can you “ping mail.google.com”? Are you running chrome directly on your Jetson without remote login?
Hi Linuxdev
Thanks.
I am running it directly on Jetson tx1. To begin with every time I started Chromium I needed to input a password for a keyring. I managed to delete/remove this password.
sojohan
So from a command prompt are you able to resolve “www.google.com”?
host www.google.com
An address I see from this is “172.217.1.196”. Can you ping this (if your host resolves a different numeric dotted-decimal address, then use that instead)?
ping 172.217.1.196
If the above work, then the issue is narrowed down to something with Chromium…otherwise it is an issue with networking.
In both cases it may be of interest to know the output from:
ifconfig eth0
# and:
route
(also tell us what kind of network you have…e.g., is the PC acting as router, or do you have a dedicated router appliance with that connected to the internet, so on)
Hi linuxdev
To your first test: host www.google.com
I get:
www.google.com has address 172.217.19.68
www.google.com has IPv6 address 2a00:1450:4005:80b::2004
Second test:
ping 172.217.1.196 (172.217.1.196) 56(84) bytes of data
(and noting else)
Third test: (ifconfig eth0)
eth0 Link encap: Ethernet HWaddr 00:04:4b:66:35:1a
inet addr: 192.168.137.4 Bcast:192.168.137.255 Mask:255.255.255.0
UP Broadcast: Multicast MTU: 1500 Metric:1
RX packets: 0 errors:0 dropped:0 orverruns:0 frame:0
TX packets: 0 errors:0 dropped:0 overruns:0 carrier:0
Collisions: 0 txqueuelen:1000
RX bytes: 0 (0.0 B) TX bytes: 0 (0.0 B)
I have a router appliance…
Thanks sojohan,
DNS is working, but not all parts of your network are being passed through. Not everyone supports ICMP (which is what ping uses), but I know that address does. So it should have replied.
What did the “route” command show? It is interesting that eth0 (from ifconfig) shows no bytes sent or received…yet DNS had been set up. Perhaps the wrong device is configured, or perhaps the router is blocking the traffic. The “route” command would tell us about default routes and might explain why eth0 was not the one sending/receiving.
Hi Linuxdev
Here is the output of route:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.137.1 0.0.0.0 UG 0 0 0 eth0
default dsldevice.lan 0.0.0.0 UG 600 0 0 wlan0
link-local * 255.255.0.0 U 1000 0 0 eth0
192.168.1.0 * 255.255.255.0 U 600 0 0 wlan0
192.168.137.0 * 255.255.255.0 U 0 0 0 eth0
Thanks,
Sojohans
Your previous ifconfig showed this on eth0:
inet addr: 192.168.137.4 Bcast:192.168.137.255 Mask:255.255.255.0
Your default route indicates that you have two default routes…one has a larger metric, this one would be used last and only if the lower metric fails. So default route for the outside world would try first to use “192.168.137.1”. For this to be valid this must be the exact address of your router.
Can you look at your router and find out if its address is “192.168.137.1”? From your Jetson what do you get from these:
traceroute 192.168.137.1
traceroute dsldevice.lan
I am wondering what “dsldevice.lan” is? Do you also have WiFi?
Hi Linuxdev
I can login to my router at 192.168.1.1 and I can see my ubuntu-tegra wifi device and the ip address is 192.168.1.176.
Thanks,
Sojohans,
So here are some observations…
192.168.1.1 is handled by WiFi, not wired. Same for 192.168.1.176. 192.168.137.x addresses are handled by wired. The addresses you are using do not correspond to the highest priority route (the route with lowest metric…eth0 is wired and lowest metric, wlan0 is wireless and uses the lower priority/highest metric).
Addresses falling outside of those subnets would be redirected first through wired, and if wired is down, switch to WiFi. Something seems off that you are logging in through the IP address which is the highest metric…as if eth0 has failed. But metric on your host PC might differ than what the Jetson is using.
It appears wired is up, but you still need to post your traceroute results to really verify which interface things are going through, especially for “traceroute 192.168.137.1”. It would be nice to see if the calls to the wired route go straight there, or if instead they try to go to WiFi in order to reach wired (which would be wrong). It would also be good to find out what “dsldevice.lan” is by seeing what traceroute says about it since this is the name given to the higher metric WiFi’s default route. This seems like something is off in configuration. Look again at the traceroute questions in #8:
https://devtalk.nvidia.com/default/topic/1036630/jetson-tx1/tx1-chromium-not-working/post/5266685/#5266685
I would actually suggest completely shutting down WiFi to test with:
sudo ifdown wlan0
# Test chromium...
# ...and then test again with only eth0:
sudo ifup wlan0
sudo ifdown eth0
# ...test chromium again...
I believe that relates to the seahorse keyring prompt.
However, regarding the issue, It appears that some issue with resolution of names take place.
What if to add dns server explicitly manually to the Jetson network interface configuration?
He has DNS lookup working, but he has more than one default network, so I’m not sure which one it is that requests are actually going over. The failing requests would be at points after name lookup has already been achieved (and further network traffic could potentially be wanting to use a different route than DNS lookup). My hope is to find out more through a combination of traceroute and from having just one default route tested at a time (not relying on the “metric” cost determining which to use).
I don’t remember the password/key ring details, and it could be this detail which is an issue…but I don’t know if it is from a failure to prompt the user, or if it is from a failure for the network to let the request go through, or for some reason completely unrelated (one thing I remember back when I ran into chromium issues originally is that I had to set it up first on a different computer before I could get it working on the Jetson…I don’t remember why this was so). Once more, the traceroute with just one default route at a time might provide information.
It appears to me that he has both ipv4 and ipv6 somehow functioning.
I am just wondering if
ping6 google.com
will resolve the domain name successfully.
Hm, in my case the addresses are slightly different, as they are regional, perhaps
host www.google.com
www.google.com has address 209.85.233.103
www.google.com has address 209.85.233.105
www.google.com has address 209.85.233.147
www.google.com has address 209.85.233.104
www.google.com has address 209.85.233.106
www.google.com has address 209.85.233.99
www.google.com has IPv6 address 2a00:1450:4010:c0b::67
I am just wondering if the chromium will open a page if putting into the address bar:
209.85.233.106
will
curl google.com
executed under terminal deliver the web page?
curl www.google.com
wget www.google.com
?
Hi,
I have now tried:
traceroute dsldevice.lan
It was succesfull with:
Hostname Error code RTT1 (ms) RTT2 (ms) RTT3 (ms)
dsldevice.lan 0 0 0 0
traceroute 192.168.137.1
Does not return anything.
On my router I can see that my tx1 is online with hostname tegra-ubuntu
When I do:
tracerute tegra-ubuntu
It was succesfull with:
Hostname Error code RTT1 (ms) RTT2 (ms) RTT3 (ms)
tegra-ubuntu.lan 0 87 4 4
When I ping tegra-ubuntu
It ran successfull with:
Bytes IP Seq TTL Time
64 192.168.1.176 0 64 11.439
64 192.168.1.176 2 64 53.193
64 192.168.1.176 1 64 30.233
Thanks,
Sojohans
Looks a bit complicated to figure out. I’d advice to get back to @Linuxdev’s advice to disable wifi (or wired ethernet) as proposed in post #10.
Some of the output is a bit odd:
Hostname Error code RTT1 (ms) RTT2 (ms) RTT3 (ms)
The “tegra-ubuntu” name is strictly from the router though, it isn’t from the internet DNS server (you could also have this in “/etc/hosts”).
Routing just doesn’t see right. If you run “sudo ifdown wlan0”, then this is only temporary (you could then “sudo ifup wlan0” or reboot). It would be very useful to try to see how things work when wlan0 is down and only the lower cost route (metric 0) of eth0 is up. Or the reverse, see how wlan0 behaves when up but when eth0 is down. Something in your WiFi setup isn’t quite right.
The earlier comment to try with “wget” or “curl” is still a good idea. Or using any other browser besides chromium…knowing how other download tools or browsers behave would be quite useful if you can test other software to see if other software has the same issue or if the issue sticks to chromium. Try other browsers also after “sudo wlan0 down”.
Exactly, disabling one of two active interfaces will allow to narrow down the case.
Moreover you may clone mac address of your router to your ethernet interface and get rid of the router and connect the WAN cable to your Jetson and approach getting dhcp from your ISP to your ethernet port of the Jetson as if you do that with the router. That will allow to narrow down the case even further in my opinion.
Hi all,
I finally got it to work.
When I used
sudo ifdown eth0
I was able to use my wifi connection.
Thanks !!!
Sojohans