On Sunday 24 September 2017 00:28:34 Alan Corey wrote: > > I'm out of ideas. And obviously I cannot configure this rock64 > > until the network works. > > It sounds like only 1 machine doesn't work, your email got out after > all. > > > and 4 other wheezy machines work as expected thru this > > So the rock64 has a chance of working. > > You don't have something blocking certain MAC addresses, maybe by not > having added it to a table of allowed ones? Access control list for > the router maybe? > > You could try an arp -a but I don't think it'll work past the router. > How about traceroute 8.8.8.8? Sounds like it's not getting past the > router for whatever reason so it'll probably map up to there and sit > there doing * * *. Reboot the router? I don't know what it is in > this case. Traceroute shows me > > zero# traceroute 8.8.8.8 > traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets > 1 192.168.43.1 (192.168.43.1) 4.728 ms 4.678 ms 4.171 ms > 2 * * * > 3 172.21.192.194 (172.21.192.194) 207.516 ms 226.515 ms 226.393 > ms 4 107.77.252.106 (107.77.252.106) 225.585 ms 338.241 ms 340.453 > ms 5 107.77.252.2 (107.77.252.2) 354.467 ms 375.499 ms 381.571 ms > 6 107.77.254.116 (107.77.254.116) 381.075 ms 363.133 ms 363.692 ms > 7 12.83.186.186 (12.83.186.186) 365.420 ms 363.726 ms 364.198 ms 8 > 12.83.185.153 (12.83.185.153) 390.378 ms 384.479 ms 392.005 ms 9 > 12.122.28.125 (12.122.28.125) 405.034 ms 404.243 ms 401.788 ms 10 > 12.122.141.221 (12.122.141.221) 423.779 ms 425.877 ms 444.198 ms 11 > 12.247.147.22 (12.247.147.22) 444.313 ms 447.099 ms * > 12 108.170.249.161 (108.170.249.161) 448.599 ms * * > 13 216.239.56.91 (216.239.56.91) 519.419 ms 108.170.228.14 > (108.170.228.14) 512.205 ms 216.239.54.229 (216.239.54.229) 509.196 > ms > 14 209.85.254.185 (209.85.254.185) 517.461 ms > google-public-dns-a.google.com (8.8.8.8) 502.167 ms 506.646 ms > zero# traceroute is not installed, but arp is: (and says the same this in a different language) root@rock64Sheldon:/etc/init.d# traceroute shentel.net -bash: traceroute: command not found root@rock64Sheldon:/etc/init.d# arp -a voipmonitor.wci.com (204.11.201.10) at <incomplete> on eth0 *router.coyote.den (192.168.71.1) at 4c:e6:76:ad:34:0a [ether] on eth0 propjet.latt.net (204.2.134.164) at <incomplete> on eth0 time-a.timefreq.bldrdoc.gov (132.163.4.101) at <incomplete> on eth0 mdnworldwide.com (66.135.44.92) at <incomplete> on eth0 eterna.binary.net (216.229.0.49) at <incomplete> on eth0 pacific.latt.net (204.2.134.163) at <incomplete> on eth0 ? (204.111.6.122) at <incomplete> on eth0 soft-sea-01.servers.octoshape.net (50.22.155.163) at <incomplete> on eth0 awesome.bytestacker.com (198.58.110.84) at <incomplete> on eth0 time-c.nist.gov (129.6.15.30) at <incomplete> on eth0 ntp.your.org (204.9.54.119) at <incomplete> on eth0 time-b.nist.gov (129.6.15.29) at <incomplete> on eth0 time-a.nist.gov (129.6.15.28) at <incomplete> on eth0 2.time.dbsinet.com (199.223.248.100) at <incomplete> on eth0 ha81.smatwebdesign.com (198.58.105.63) at <incomplete> on eth0 155-94-238-29-host.hostbrew.com (155.94.238.29) at <incomplete> on eth0 *coyote.coyote.den (192.168.71.3) at 00:1f:c6:62:fc:bb [ether] on eth0 119.189.154.104.bc.googleusercontent.com (104.154.189.119) at <incomplete> on eth0 hydrogen.constant.com (108.61.73.243) at <incomplete> on eth0 time-b.timefreq.bldrdoc.gov (132.163.4.102) at <incomplete> on eth0 ? (208.76.53.137) at <incomplete> on eth0 frigg.fancube.com (154.16.245.246) at <incomplete> on eth0 four0.fairy.mattnordhoff.net (66.228.59.187) at <incomplete> on eth0 root@rock64Sheldon:/etc/init.d#
And except for the local (*marked) machines, is "incomplete". I just powerdown reset the router, no change. I just noted the time was wrong, so I set /etc/timezone to America/New_York and restarted ntp. No diff so I commented the unreachable pool s out and enabled it to listen on the local lan. DD-WRT is set to broadcast it, but thats made no diff either. At 2:41 local, it says: root@rock64Sheldon:/etc/init.d# date Sun Sep 24 06:41:34 UTC 2017 Which is UTC I think, its too late in the evening, so I'm headed back to the sack. Maybe it will fix itself in the night? Thanks Alan. > Having fun with this ZeroW, which runs on about 1 watt. And it's > about 2 inches long. > > On 9/23/17, Gene Heskett <ghesk...@shentel.net> wrote: > > On Saturday 23 September 2017 20:28:08 Alan Corey wrote: > >> "Destination Host Unreachable" doesn't mean it didn't resolve, it > >> can mean a cable's unplugged or your netmask isn't right or in > >> this case it's not getting outside your LAN for whatever reason. > >> Try pinging an outside IP like 8.8.8.8 (a public Google DNS > >> server). Ping and dns lookup are 2 different things. > > > > Ping fails to any address beyond the router, by name or address: > > pinging the router: > > root@rock64Sheldon:~# ping router > > PING router.coyote.den (192.168.71.1) 56(84) bytes of data. > > 64 bytes from router.coyote.den (192.168.71.1): icmp_seq=1 ttl=64 > > time=1.60 ms > > 64 bytes from router.coyote.den (192.168.71.1): icmp_seq=2 ttl=64 > > time=1.01 ms > > 64 bytes from router.coyote.den (192.168.71.1): icmp_seq=3 ttl=64 > > time=1.00 ms > > > > This machine: > > root@rock64Sheldon:~# ping coyote.coyote.den > > PING coyote.coyote.den (192.168.71.3) 56(84) bytes of data. > > 64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=1 ttl=64 > > time=0.878 ms > > 64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=2 ttl=64 > > time=0.868 ms > > 64 bytes from coyote.coyote.den (192.168.71.3): icmp_seq=3 ttl=64 > > time=0.853 ms > > > > my ISP: > > root@rock64Sheldon:~# ping shentel.net > > PING shentel.net (204.111.6.122) 56(84) bytes of data. > > From 192.168.71.2 (192.168.71.2) icmp_seq=1 Destination Host > > Unreachable From 192.168.71.2 (192.168.71.2) icmp_seq=2 Destination > > Host Unreachable From 192.168.71.2 (192.168.71.2) icmp_seq=3 > > Destination Host Unreachable > > > > googles dns: > > root@rock64Sheldon:~# ping 8.8.8.8 > > PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. > > From 192.168.71.2 icmp_seq=1 Destination Host Unreachable > > From 192.168.71.2 icmp_seq=2 Destination Host Unreachable > > From 192.168.71.2 icmp_seq=3 Destination Host Unreachable > > > > I can't see anything in the router settings that would block an > > outside the lan address, and 4 other wheezy machines work as > > expected thru this router. > > > > I'm out of ideas. And obviously I cannot configure this rock64 > > until the network works. > > > > Humm, iptables is running, and I've not messed with that since 15 > > years ago, don't use it on the local lan net. Killed it and unloaded > > the modules. local ping still works, outside still dead. Restarted > > the networking, which did not restart iptables or load its modules, > > but the bahavior is unchanged. > > > > Bedtime on this side of the pond. Tomorrow is a new day. > > > > Thanks Alan. > > > >> On 9/23/17, Gene Heskett <ghesk...@shentel.net> wrote: > >> > On Saturday 23 September 2017 13:28:51 Mark Morgan Lloyd wrote: > >> >> On 23/09/17 16:45, Gene Heskett wrote: > >> >> > On Saturday 23 September 2017 12:26:23 Mark Morgan Lloyd wrote: > >> >> >> On 23/09/17 15:00, Gene Heskett wrote: > >> >> >>>> I've never had problems with dd provided that the > >> >> >>>> USB->SDcard adapter's OK: what command are you using? > >> >> >>> > >> >> >>> The usual syntax: > >> >> >>> dd if=somefile bs=512 of=somedevice, and in the case of sd > >> >> >>> card copying, > >> >> >> > >> >> >> Tell us the /exact/ command you're using. > >> >> >> > >> >> >>> since no 2 are alike so I usually look at the src's declared > >> >> >>> size in dmesg and set count=that-5k so it doesn't error out > >> >> >>> copying a pny 32GB to a Sandisk 32GB. Etcher, which is > >> >> >>> faster, has the same problem & pitches a fit when it can't > >> >> >>> find room to put the last 10 sectors. I've had poor luck > >> >> >>> with sandisk anything though. pny, samsung is good stuff. So > >> >> >>> I bought pny last night. > >> >> >> > >> >> >> The first thing I'd say is that almost all of the problems > >> >> >> I've had stopped when I changed the card reader. I'm now > >> >> >> using one badged Canyon which specifically has a Micro-SD > >> >> >> slot, i.e. I'm no longer trying to use an adapter which is > >> >> >> universally regarded as being unwise. > >> >> > > >> >> > I have 2 vivitar's, both with microsd slots. They work 100% > >> >> > when burning an image file from armbian jessie so far. > >> >> > > >> >> >> You don't need that bs=512 and trying a sector-by-sector copy > >> >> >> on a device that uses far larger blocks might be unwise. I > >> >> >> use bs=128M > >> >> > > >> >> > I'll give that a shot. > >> >> > > >> >> >> Don't give dd an explicit block count, let it copy > >> >> >> everything. That 5k in particular could be worse than useless > >> >> >> since it doesn't correspond to a physical or logical block > >> >> >> size. > >> >> > > >> >> > no two sd cards, even from the same maker, are exactly the > >> >> > same size due to bad block replacements before they are even > >> >> > blister packed for sale. This is the exact reason they ship > >> >> > stripped images that require you resize them on the machine > >> >> > they will live in. What we dearly need is a utility to > >> >> > generate the iso shrunken to only that which is actually used. > >> >> > Or do we have such a critter and I don't know about it? > >> >> > >> >> I know all that, and I've spent a lot of time talking to these > >> >> things directly, measuring times, checking pattern-sensitivity > >> >> and so on. > >> >> > >> >> And I'd remind you that while we're using similar hardware, > >> >> you're having problems, I'm not. What does that suggest to you? > >> >> :-) > >> >> > >> >> >> Zeroing the target device first might help, i.e. copying from > >> >> >> /dev/zero > >> >> >> > >> >> >> If the source device has been partitioned to be full, then > >> >> >> shrink first the top filesystem and then the top partition to > >> >> >> make sure that what you're copying is substantially smaller > >> >> >> than the target device. Alternatively a useful hack is to set > >> >> >> up your source device with an extra partition at the top, > >> >> >> e.g. FAT just in case you want to move data around between > >> >> >> OSes, then you can delete the top filesystem and partition > >> >> >> before using dd and be confident that you won't be doing an > >> >> >> incomplete copy. > >> >> > > >> >> > Seems like something that could be scripted. > >> >> > >> >> Yes, for example by the script that Raspbian runs on its first > >> >> startup. > >> >> > >> >> Don't fool around, just make sure that the valid data on the > >> >> source card is substantially smaller- and I mean 100s of Mb, not > >> >> a few Kb- than the destination card. > >> >> > >> >> But my suspicion is that you're doing something wrong like > >> >> trying to copy one partition when you should be copying all > >> >> partitions. But since you won't give us an example of the > >> >> command you're using we can't be certain either way on that. > >> > > >> > I did, but it was for dd. I have sincefound piclone will run ok, > >> > if itsthe first thing after a reboot. Dirty the memory with > >> > something else and its dead. So I now have the terrabyte hd > >> > cloned from the base of the card. If I ever get it to boot from > >> > it, expand the filesystem to a terrabyte. > >> > > >> > Next problem, I installed the minimal stretch to a 32GB card, and > >> > if don't think it resized that 230 mb image, but I'm logged into > >> > it, so df gives me: > >> > rock64@rock64:~$ df > >> > Filesystem 1K-blocks Used Available Use% Mounted on > >> > udev 2007908 0 2007908 0% /dev > >> > tmpfs 401960 5512 396448 2% /run > >> > /dev/mmcblk1p7 30574584 931612 28360464 4% / > >> > tmpfs 2009784 0 2009784 0% /dev/shm > >> > tmpfs 5120 4 5116 1% /run/lock > >> > tmpfs 2009784 0 2009784 0% /sys/fs/cgroup > >> > /dev/mmcblk1p6 102182 41636 60546 41% /boot/efi > >> > tmpfs 401956 0 401956 0% /run/user/1000 > >> > > >> > So no, its not needing expansion, the whole card is there. > >> > > >> > I've carved up a /etc/network/interfaces.d/eth0 file with the > >> > usual entries, looks like this: > >> > rock64@rock64:~$ cat /etc/network/interfaces.d/eth0 > >> > #allow-hotplug eth0 > >> > auto eth0 > >> > iface eth0 inet static > >> > address 192.168.NN.2 > >> > netmask 255.255.255.0 > >> > gateway 192.168.NN.1 > >> > > >> > ditto, I made a real /etc/resolv.conf, looks like this: > >> > rock64@rock64:~$ cat /etc/resolv.conf > >> > domain coyote.den > >> > nameserver 192.168.NN.1 > >> > search hosts dns > >> > > >> > Both are made immutable so n-m can't putz with them if it is > >> > running. According to ps, it is not. If its gone from stretch, > >> > I'll need a 6 pack to celebrate that properly. :) > >> > > >> > So my local network is working as expected. BUT: > >> > root@rock64:/etc# ping -c1 yahoo.com > >> > PING yahoo.com (98.138.253.109) 56(84) bytes of data. > >> > From 192.168.71.2 (192.168.71.2) icmp_seq=1 Destination Host > >> > Unreachable > >> > > >> > Note that the dns request did resolve. > >> > > >> > But my dns requests are probably being answered by dnsmasq in the > >> > router. I cannot find anything in the routers copious settings > >> > (it's DD-WRT) that would prevent a connection, but it refuses to > >> > pass. I've tried several ipv4 addresses in that 192,168.nn block. > >> > No other machines, 5 more, on this local net are being denied > >> > network access. > >> > > >> > Ideas? I'm nearly out of hair. But its been slowly thinning for > >> > 82+ years too so I can't blame it on this too loudly. > >> > > >> > Thanks Mark. > >> > > >> > Cheers, Gene Heskett > >> > -- > >> > "There are four boxes to be used in defense of liberty: > >> > soap, ballot, jury, and ammo. Please use in that order." > >> > -Ed Howdershelt (Author) > >> > Genes Web page <http://geneslinuxbox.net:6309/gene> > > > > Cheers, Gene Heskett > > -- > > "There are four boxes to be used in defense of liberty: > > soap, ballot, jury, and ammo. Please use in that order." > > -Ed Howdershelt (Author) > > Genes Web page <http://geneslinuxbox.net:6309/gene> Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene>
