arox
-
Posts
391 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by arox
-
-
@lex, perfect!
Also if someone need custom camera modules with wider lense, send me a PM.
Can you explain a bit more : I have got a cam for a raspberry pi some years ago and was really disappointed. The fixed focus wide angle lens makes it quiet useless. With the tiny aperture, it is even not granted than the diffraction allow to reach sensor definition on those devices. So is there cam with "real lens" available for direct connection on these boards ?
-
here is my conf file of isc-dhcp-server:
subnet 192.168.8.0 netmask 255.255.255.0 { range 192.168.8.10 192.168.8.254; option routers 192.168.8.2; option subnet-mask 255.255.255.0; option broadcast-address 192.168.8.254; option ntp-servers 192.168.8.1; option netbios-name-servers 192.168.8.1; option netbios-node-type 8; }so added the line:option domain-name-servers 8.8.8.8, 8.8.4.4;and change the router ip to 192.186.8.1.and now it is working.I tried dnsmasq before, but -probably i couldn't configure it properly- it didn't work as dhcp server, so than i decided to change to isc-dhcp-server. Maybe, if i will have time for it, i will try to check the dnsmasq again. Thanks for the help"option netbios-name-servers 192.168.8.1;"
Note sure dnsmasq can do netbios name service ... But with a simple line :
dhcp-range=192.168.8.10,192.168.8.254,255.255.255.0,12h
it should works. (By default, it will advertise itself as router)
-
To point to a nameserver, put 'nameserver 8.8.8.8' in /etc/resolv.conf on your workstations.
Your isc-dhcp-server config is probably bad. It should distribute everything properly to your hosts.
And if I were you, I would use dnsmasq that can serve as DHCP server and DNS cache/relay server.
Nota Bene :
"so i guess here the gateway missing is the problem and i think i don't have any default nameserver set on my orangepi+."
Your orangepi+ is your nat/router, it doesn't really need to point to a nameserver. A nameserver pointer is just a user interface help to avoid using addresses or fill /etc/hosts. But it is the best place to provide name service for the users worstation (with dnsmasq - much lighter than bind), and in that case you will probably want to fill /etc/resolv.conf on orangepi+
-
You should verify you netmask and your default router on 192.168.8.11 and 192.168.8.13 !
(netstat -rn)
Your default router should be 192.168.8.1 if I understand your network configuration and the mask 255.255.255.0
-
Traceroute is a tool to test network routing. You connect in a shell on a host on lan 192.168.8.0 an do a traceroute to a host behind your router/nat, for example in 192.168.1.x or in Internet.
(apt-get install inetutils-traceroute)
Ex : traceroute www.sncf.com
1 192.168.1.1 (192.168.1.1) 1.607 ms 3.134 ms 2.470 ms
2 do-5-8-189-207-254.fbx.pad.net (88.111.207.254) 29.190 ms 28.712 ms 29.376 ms
3 43.228.12.190 (43.228.12.190) 31.137 ms 31.738 ms 31.446 ms
......
It will send ICMP echo request with a limited and progressive "cross router" allowance (Time To Leave). Then each router in the path will send back an TTL exceeded and the tool will present 1 line per hop that succeed with 3 response time sample. (and * * * when it fails)
If you just reach your nat/router and don't see a address ping beyond, then your routing/translation fail. If you get no response or it presents more lines, then it is another problem.
-
Et avec un traceroute, vous bloquez où ?
-
When you will have found that you need to get rid or "lightdm", then start here :
http://askubuntu.com/questions/679419/how-to-make-auto-login-work-in-ubuntu-no-display-manager
-
I believe you are right. I thought something like this too.
I tried use "After=rpcbind.target" but it did not work too.
Main questions:
Why?
And how to fix it?
Well, you can either do reverse engineering on systemd, disable all unneeded crap and start it in /etc/rc.local, or try to guess what is wrong.
As an example, I found out that my nfs mounting worked in an erratic way because I had not defined the server in /etc/hosts. So sometimes mounting worked (because in is defined in my DNS server), sometimes it worked if I forced the mount in /etc/rc.local, and sometimes in didn't work at all during boot ...
A boot script to do the same thing as systemd should have about 20 lines and be easily manageable. With parallelism, you can never be sure of the order in which the things are done, and with dependencies to remote services, you aren't even sure it will boot. Every time I change a line, reboot fail but second reboot work ?!?
Check you don't need external host name resolution with transmission at startup, try to force "service rpcbind start" in rc.local.
-
Yeah, I know this. Those customers where 'everything is under control' have slow networking since admins chose high-end managed switches where they're able to mis-configure anything while those with the el cheapo stuff enjoy flawlessly working fast network
Slow networking is most of the time "catastrophic slow" networking due to frame drops at link layer that need a long delay retransmission timer in transport layer. Or morons that put filters everywhere on switches that need then to handle frames in (tiny) processor instead of ASIC.
But "admins" don't even realize it, because they are not using telnet/ssh (the round trip delay for echoing each character make it evident) and never have a look at interfaces/port error counters (in a LAN with switches, you should have zero collision, FCS or short frame errors because you are peer to peer and full duplex with a "store and forward" device). But people know a lot of acronyms but very little on the technology implied.
-
try to launch : /usr/share/doc/bluez-tests/examples/monitor-bluetooth
I never tried to use a keyboard ...
I presume that the keyboad auto-connect the profile when powered on, GUI intercept device base-band connection event and launch an agent to pair (although it is already paired) and if you respond to the agent it reset the connection.
Type help in "bluetoothctl", you will see an "agent" command but I never used it. (remove device to start from beginning)
WTF ? Probably that it uses 3 state machines (one in the kernel, one in bluetoothd, one in GUI), as if 3 persons where trying to drive your car ...
If I understand your problem, it is how to enable a keyboard in GUI with no keyboard to answer stupid questions ? Perhaps by connecting first time with "ssh -Y" from another X11 host ?
You could perhaps try in /etc/bluetooth/input.conf if "UserspaceHID=true" helps ...
-
- Check your adapter is enabled by "hcitool dev" (if not, you may need "hciconfig up", or "rfkill unblock all", but this is probably not the problem if you can use "hcitool scan).
- Try "bluetoothctl"
* it should annuounce [new] controller ... (or you have a problem and should se in the logs ...)
* discoverable on
* pairable on
* scan on
* try to force a connection attempt with device (switch on, pair button, l2ping <dev addr>) until you get a message of your device with its bt-address
* trusted <bt-address>
* connect <bt-address>
also "* pair <bt-address>", but all of "enabling commands" and "trust/pair/force connection" commands should not be necessary. The most usefull is "trust".
-
- Check your adapter is enabled by "hcitool dev" (if not, you may need "hciconfig up", or "rfkill unblock all", but this is probably not the problem if you can use "hcitool scan).
- Try "bluetoothctl"
* it should annuounce [new] controller ... (or you have a problem and should se in the logs ...)
* discoverable on
* pairable on
* scan on
* try to force a connection attempt with device (switch on, pair button, l2ping <dev addr>) until you get a message of your device with its bt-address
* trusted <bt-address>
* connect <bt-address>
-
So you most probably will hate everything that would make life easier?
Eg. installing ZeroConf for Windows (I assume you're using Windows -- in OS X everything should be fine and in Linux it's just avahi-daemon that needs to be installed).When there's no DHCP server the OPi Zero like any other machine running a half-decent OS should choose a so called link-local address (169.254.x.x) which gets announced through ZeroConf/Bonjour -- in Windows known as APIPA and working there for at least 15 years or so.Oops, tried it out myself and had to realize that it's broken for reasons unknown to me. Apologies! It might work if you change your local IP address to 169.254.1.1 and try a broadcast ping (169.254.255.255) and check 'arp -a' output later. But serial console (or activating DHCP temporarly) seems more easy.
I think response to broadcast ping may have been disable (for security reason ?). I didn't manage to use it for a long time.
Please don't back up people that try to port "blue screen" technology on linux. I have seen the funniest things on network with appletalk 3 level physical/logical/service paradigm (access to wrong printer) and Microsoft abuse of layer 3 broadcast helpers (broadcast storm propagated threw the WAN). Microsoft programmers are not bad : bad choices are made upstream to offer functionality with little concern to security.
Automatic configuration of address is of no use : you have to choose a unique name anyway. You could as well use a fixed well known local ip address and force user to change it a first connection - as it is done for root password.
-
Well, I had the recollection that rpc-based protocols couldn't work without it. Nevertheless if it is not a missing lo interface configured or a missing localhost name resolution, you could have a problem with a "missing portmapper" that is a missing rpcbind process ready to register RPC services, but it is only an idea.
-
I used this one this a RPI. I just have ported my a2dp server on bluez5/pulseaudio/nanopi air (internal BT chip)
- compatibility depends on bluez (and btusb kernel module) and not on board or distro, if customers report it works with "linux" or "ubuntu", then you will be able to have it working.
- better use a class I dongle if you want a good range - but you will anyway hardly reach more than a few meters because a2dp device are generally class II
- even better use a nanopi air : with eMMC and internal BT chip, you get the same price than an $8 board with crappy SD card and crappy dongle. Without antenna (not provided) this board is unusable, but with an IPX cheap antenna you get as good a range than with class I dongle for that usage.
- be aware that with bluez5, you need pulseaudio, you can only use one BT sink at a time and you need workarounds to handle bugs in (pulse, bluez, dbus), workarounds that may depend on device specific profile connection management.
-
Isn't it a problem of lo interface up timing ?
do you have :
"127.0.0.1 localhost"
in /etc/hosts
-
Isn't it a problem of lo interface up timing ?
-
@chaoswk: I can confim the exakt same peak of activity arount 7 in the morning. Even the cpu temperature rises.
Certainly updates or something.
In this context I consider your watchdog practice very unsafe: If the computer is busy, your script will lag a little,
and --pouf-- bye,bye.
Please try to install and configure watchdog package, or leave this out for some time.
best, gnasch
Or disable "updates or something". (try journalctl | grep apt)
-
His link indicates an adafruit product that clearly says :
"The power pin provides the 5V @ 500mA direct from the USB port and the RX/TX pins are 3.3V level for interfacing with the most common 3.3V logic level chipsets."
Nevertheless, the boards makers never make it clear if they use 3.3V or 5V logic and should one be confident about docs when they call 3.3V logic "TTL" ? And about TX and RX, it is always a "point of view" in a cross cable DTE to DTE.
Anyway, be also carefull that pin order is opposite between "neo" and "neo air".
-
About serial console, are you sure about TX and RX ? Did you check with another board if your adapter work and you know how to use it ?
About wifi, do you know it is unusable without aerial ?
-
But thing is that I don't like this solution.
Why ?
It is a workaround and workarounds are always ugly. Anyway you will need to check and reinstall workarounds with every new release, so I generally place my workarounds entirely in rc.local and disable what doesn't work out of the box.
-
Why that complicated? See the first link above, the 1st answer to the OP's question: https://forum.armbian.com/index.php/topic/1417-testers-wanted-g-ether-driver-h3-device-as-ethernet-dongle/?p=11105
It's just adding a few lines to the interfaces file, adding/replacing one entry in /etc/modules and you're done. On H3 device side. If Linux or OS X is on the other end of the USB cable everything might already work, ...
Why ? Because I know this way is working for me ...
You know, one of the problem with this type of setup is that you get lost in the tutorials about what concern one end of the link and what concern the other one.
Until now, I don't understand if using link local address is supposed to make auto-configuration of the host effective, possible or possibly automated. And threw which mechanism, with which OS/version/subsystem/software ...
Nevertheless, I think that armbian should do its best to facilitate the usage of USB networking (I use it on A20 and H3 - thanks to you !). USB networking is fast, economic, handy, power effective ...
But anyway my use cases are such that I never will be able to use it "out of the box" in production. But on install, it would be great. The problem is not having at present the possibility to use g_serial and g_ether simultaneously.
-
There's no need to debug anything, simply remove eth0 from a static config file and let network-manager do the job. BTW: the same question comes up here not the first time, see eg. https://forum.armbian.com/index.php/topic/591-wlan0-only-works-when-eth0-plugged-in/
Yes the link level problems seldom happens. Routing problems are the most frequents. In particular when using 2 interfaces on the same network. So either you follow tkaiser advice and stick to armbian recommendation not using old "/etc/network/interfaces" method, either you configure everything manually ...
-
Hmmm... but that still doesn't answer why connecting wired ethernet to the OPi Zero then allows the macbook to respond to arps... hmmm...
After more checking, it's almost 99% sure that the Macbook is the problem.
Doing some packet dumps on both devices, I see that the OPi Zero is requesting ARPs, but the Mac refuses to answer
On the other hand, the Mac makes ARP requests and gets responses from the OPi Zero.
Disable/Renabling the WiFi on the Mac fixes this problem
OSX 10.11.6 (15G1108)
I don't know how you are doing your tests. When you want to debug low-level network problems, it is often necessary to use a network protocol analyzer with probes inserted on the wires links. (You could use wireshark on a computer with 2 ethernet interfaces - but it is a time-consuming job and requires a good knowledge of network technology)
And don't forget that your AP is himself a bridge and may be a part if not the cause of the problem.
By the way, what is your wifi mac address ? Beware of bad choices in user (system) configured hardware addresses ...
SD card performance
in Reviews, Tutorials, Hardware hacks
Posted