Posts by iwl

    Die Idee ist ganz praktisch CanBus Packete sind UDP Packeten ja ähnlich.
    So Sachen wie wiederholen oder nicht könnte man sicher mit Socket Optionen abbilden.
    Wenn ich UDP Packete versende werden die ja auch nur einmal versendet.
    Das blöde ist nur dass das mit den Can Messages nun anders ist, hat mit dem Ansatz aber gar nichts zu tun.

    Hallo Leute,


    ich habe gerade festgestellt, das wenn man einen Frame cansendet und der nicht geAckt wird dieser unendlich gesendet wird und die nachfolgenden Messages den Buffer füllen, alles blockiert ist.
    Kann man das abstellen?
    Man findet zum Can / Utils so schlecht Doku.

    Das Programm was Du brauchst ist SOCAT kann das alles und musst gar nichts programmieren.
    Kannst einen Pi Zero W nehmen, oder einen Pi 3, am einfachsten da einen USB zu RSxyz Adapter dran der Unterstützt wird, kannst auch an die Onboard seriellen Schnittstellen einen RS232 / 485 Wandler dran hängen.

    Hallo,


    /etc/network/interfaces :


    mapping wlan*
    script printf "wlan\n"


    auto wlan0 wlan1


    iface wlan ...


    funktioniert bei mir nicht, kommt:
    wlan0=wlan0 unbekannt
    wlan1=wlan1 unbekannt


    was ist falsch?


    iwl

    Mit dem ES Explorer auf Android Handy kann man wie es aussieht schnell nen WLAN Hotspot aufmachen und was freigeben, vermutlich genau für sowas gemacht.
    Ansonsten in einer Firma mal eben nen Hotspot aufmachen und Rechner verbinden, kann Ärger geben oder die Rechner sind dafür sowieso gesperrt.


    Gesendet von meinem C6603 mit Tapatalk

    Wie benutzen dann die Nutzer FTP, mir ist nicht bewusst in den letzten Jahren FTP zu nutzen, wo nutzt Du denn FTP?
    Wobei ohne App wüsste ich jetzt auch nicht wie man generell von Android auf so einen mobilen Server zugreift, evtl automatisch eine Webseite bei Verbindung zum Accespoint wie in den Hotels, ist dass nicht immer 1.1.1.1 oder so?


    Gesendet von meinem C6603 mit Tapatalk

    Ich denke FTP wird schon gehen.
    Wie kommst Du gerade auf FTP, wer macht das noch, Samba Shares sind wahrscheinlich besser.
    Das mit am Laptop ist so eine Sache, wenn der dann Mal bootet stürzt das Teil ab, auch ist besser man kann das günstig positionieren, usw., das sollte ganz autark gehen.


    Gesendet von meinem C6603 mit Tapatalk

    Meinte ich, ohne 3G gibt's sowas auch sicher noch günstiger.


    Der Coin hat keine Batterie, ansonsten sind die Specs unter Pi, das wäre bei meinen Teilen auch, deswegen geht nur Openwrt, für Debian wie beim Pi reicht es da nicht.


    Gesendet von meinem C6603 mit Tapatalk

    Es gibt da so WLAN Router/ Repeater mit Hotspot Akku SD-Karte um die 40 Euro bekommst Du so billig und Kompakt mit Raspi nicht hin, Zero vielleicht.
    Schau bei Openwrt was für aktuelle Geräte unterstützt werden, ist auch ein Linux.


    Gesendet von meinem C6603 mit Tapatalk

    Wie gesagt sollte eth0 keine IP-Adresse haben, wo wird die denn gesetzt, lösche das.
    Statt dessen musst Du die Bridge zwischen eth0 und wlan 0 auf dem Raspi schalten, google mal wie man das macht, hat mit IP nix zu tun, ist drunter.
    Ich bin allerdings nicht 100% sicher ob man zwischen eth und wlan Ethernet Bridges machen kann.
    Sonst musst Du das mit Routing/IP-Tables machen.
    Google mal Ethernet Bridge WLAN Linux


    Gesendet von meinem C6603 mit Tapatalk

    Wenn Du eine Bridge zwischen wlan0 und eth0 machst muss dafür weder wlan0 noch eth0 eine IP-Adresse haben, die IP-Adresse hat die Kamera und wenn die Bridge funktioniert bekommt die die über DHCP von Deinem Router im Ethernet.
    Damit Dein Pi Netz hat sollte wlan0 eine IP-Adresse für den Pi haben, eth0 muss dagegen keine haben wenn eth0 und wlan0 eine hätten wäre der pi dann wegen der Bridge mit 2 Adressen im gleichen Netz.


    Gesendet von meinem C6603 mit Tapatalk

    Nach langem probieren habe ich jetzt hinbekommen, dass man das Ethernet stecken und ziehen kann und wlan runter und raufgefahren wird, beide dabei abwechselnd die gleiche IP benutzen und meist ssh dabei überlebt, letzteres kann vielleicht mit ARP Broadcasts nach Schnittstellen Wechsel noch verbessert werden.


    Ich musste alles mögliche ändern interfaces, wpa-config, ifplug und andere Scripte, weil es an so vielem hängt musste man an allen Ecken probieren und wenn es dann mal ging, schauen was es nun von den Änderungen nicht braucht, etc.


    Es geht eigentlich stabil, ist aber sicher noch weiter optimierbar, systematisch und funktional.


    Allerdings erst mal auf einem BananaPi mit internen eth und usb wlan, bei raspberries wird es auch gehen.


    Beim USB Ethernet am Pizero ist jetzt noch das Problem, dass ifplug da connect nicht erkennen kann, immer connected wenn up disconnected wenn down.


    Allerdings gibt es /sys/class/net/carrier und das zeigt 1 / 0 an wenn Kabel gesteckt / nicht, kann man mit ip link / ip monitor link monitoren (RTNetLink)
    Unschön ist das man nun nach ifdown ifconfig up machen muss, damit das detektieren funktioniert und ifup dann force braucht oder ifconfig down davor oder man macht ifup / down selbst neu und einen neuen Dämon um ip monitor link / RTNetLink braucht man auch.
    Man müsste also eine ganze Menge machen um das mal alles sauber zu haben.

    Das Problem liegt bei dhclient, wenn für wlan0 gerufen macht der auch einen dhcp-request für eth0 und schreibt den lease ins wlan0 lease file, jetzt ist die Frage ob das ein Bug oder Feature ist und wenn letzteres wo abschalten, wlan dauert natürlich meist länger und eth0 dann schon oben, mag auch ein Einfluss sein:


    dhclient -v -pf /run/dhclient.wlan0.pid -lf /var/lib/dhcp/dhclient.wlan0.leases wlan0


    Internet Systems Consortium DHCP Client 4.3.1
    Copyright 2004-2014 Internet Systems Consortium.
    All rights reserved.
    For info, please visit https://www.isc.org/software/dhcp/


    Listening on LPF/eth0/00:e0:4c:53:44:58
    Sending on LPF/eth0/00:e0:4c:53:44:58
    Listening on LPF/wlan0/b8:27:eb:27:cc:e1
    Sending on LPF/wlan0/b8:27:eb:27:cc:e1
    Sending on Socket/fallback
    DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
    DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5
    DHCPREQUEST on eth0 to 255.255.255.255 port 67
    DHCPOFFER from 192.168.3.1
    DHCPREQUEST on wlan0 to 255.255.255.255 port 67
    DHCPOFFER from 192.168.3.1
    DHCPACK from 192.168.3.1
    RTNETLINK answers: File exists
    Restarting ntp (via systemctl): ntp.service.
    bound to 192.168.3.46 -- renewal in 38678 seconds.

    Also ich komme dem Problem auf die Spur und zwar kommen irgendwie die eth0 dhcp leases mit in das wlan0 dhclient lease file, während in das eth0 dhclient lease file die wlan0 dhcp leases nicht reinkommen.


    wenn dhclient -r ... wlan0 ... aufgerufen wird werden so auch die eth0 leases mit "gecancelt" und deswegen keine Verbindung.


    Wenn ich die eth0 dhcp leases aus dem wlan0 file lösche bleibt bei ifdown wlan0 eth0 oben.


    wenn ich dann ifup wlan0 mache sind die eth0 leases auch wieder mit im wlan file.


    Ich vermute das Problem hängt irgendwie mit dem komplexeren ifup wlan0 über wpasupplicant zusammen, in den mehr Scripten die es da braucht ist irgendwo ein Fehler.


    Dann noch etwas wildes ifup/down wegen ifplugd und geht beides nicht, vielleicht gibt es auch noch ein paar mehr Probleme.


    Man muss ja für wpa-roam iface wlan0 inet manual schreiben in interfaces und das dhcp kommt dann anders zustande irgendwie...


    Bzw braucht es dafür dann diese interface default inet dhcp Zeile in interfaces, bekommt wlan0 dann irgendwie noch einen anderen Namen von wpasupplicant ??

    Was heißt Originalzustand, es ging ja von Anfang an nicht auf dem Zero, auf den anderen Pis geht es ja und die Probleme wegen dem eth waren schon ohne dass der jemals Verbindung hatte, kann also am DHCP nicht liegen.
    Und der andere Pi ist mit eth0 und wlan0 im gleichen Netz und nicht so große Probleme.
    Da war nur kein ifplugd drauf und fuhr so eth0 nicht runter um auch über wlan0 zurückzupingen ohne Kabel.