vagrantc has quit [Quit: leaving]
calculus has quit [Ping timeout: 264 seconds]
calculus has joined #beagle
calculus has quit [Ping timeout: 272 seconds]
calculus has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
thinkfat has joined #beagle
thinkfat_ has quit [Ping timeout: 252 seconds]
vagrantc has joined #beagle
calculus has quit [Ping timeout: 252 seconds]
calculus has joined #beagle
jkridner[m] has quit [Ping timeout: 264 seconds]
mvaittin has quit [Ping timeout: 264 seconds]
shoragan[m] has quit [Ping timeout: 264 seconds]
<zmatt> there's no need to configure a static ip for that
<zmatt> also any source from 2013 should almost certainly be ignored
<zmatt> oh they both left
<set_> @zmatt: Hello!
<set_> If I was to initialize a PRU in Linux, could I do it?
<set_> Say I want PRU to handle pin P8_15...what step in Linux would I take on the BBBlue?
<zmatt> learning to program would be a good step 1
<set_> Fine.
<zmatt> (I'm barely awake and not in the mood for hand-holding)
<set_> Otay! Well, see you all later!
<set_> I have PRU Assembler V. 0.87!
<set_> Is that not old enough or not new enough?
<set_> From what you just typed, it is from 2013.
<set_> I think it is too old.
<set_> Off to find more docs.
<zmatt> pasm is what's used with uio-pruss, clpru is what's used with remoteproc-pru (though py-uio can also load executables produced by clpru while still using uio-pruss)
<set_> Okay. I am using UIO for PRUs.
<zmatt> me too
<set_> This, /bin/echo pruecapin_pu > /sys/devices/platform/ocp/ocp:P8_15_pinmux/state, is the command I am using.
<set_> But...state is at default.
<set_> Not 1.
<set_> Would I use your lib. to find the P8_15_pinmux/state?
<set_> I am on the BBBlue (still).
<set_> For instance, I typed config-pin -q p8.15 and the output was default.
<set_> I am trying...I found further into the system under /sys/devices/platform/ocp/ocp:P8_15_pinmux/, there are many ideas.
<set_> All of which are null or default.
<set_> Then, I came across the 'power' dir.
<set_> and then 'devices' and 'drivers'.
buzzmarshall has quit [Quit: Konversation terminated!]
<set_> And...
<set_> Then, there are eight uio dirs.
<set_> 0 - 7, respectively.
<set_> It is unlike the other pins that are easily exported as say GPIO or PWM. But...config-pin has options. The options when put in a .service file do not do anything.
<set_> I have some files to work w/ as of now. But nothing I can make use of...
<set_> Please hold. I will get the file.
<set_> Anyway, I changed some of it. It seemed that the Servo Header for Pin 2 was different for some reason.
<set_> Okay. I will try some source.
<set_> Sheesh.
<set_> Okay, okay. It is late. I will try another day, i.e. night.
<set_> GenTooMan: You would be proud. I am making notes!
<set_> @zmatt: I will get to source soon, i.e. some amount of time.
ikarso has joined #beagle
LetoThe2nd has joined #beagle
vagrantc has quit [Quit: leaving]
m-atoms has quit [Quit: Client closed]
rob_w has joined #beagle
shoragan[m] has joined #beagle
mvaittin has joined #beagle
jkridner[m] has joined #beagle
calculu5 has joined #beagle
calculus has quit [Ping timeout: 272 seconds]
Guest641 has joined #beagle
<Guest641> hi everyone, I'm using bbb with custom VPN. Currently, I'm stuck on dhclient/arp/connman. after lease IP, dhclient always send `dhcpdecline`. I used same mechanism in almost devices such as raspbian armv7/arm64, ubuntu, fedora. It works well. The thing is more weird if I invoke `dhclient -v` in command line, not in unix service, it works. Does
<Guest641> anybody encounter that? Could some one help me? Thanks
<Guest641> ```Jun 11 15:30:42 beaglebone playio-vpnc[25765]: INFO : Start VPN Client if not yet running...
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {create} index 103 type 1 <ETHER>
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {update} flags 4098 <DOWN>
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {newlink} index 103 address D2:97:BA:73:B0:00 mtu 1500
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {newlink} index 103 operstate 2 <DOWN>
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {newlink} index 103 address 5E:05:C7:7C:1A:E4 mtu 1500
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {newlink} index 103 operstate 2 <DOWN>
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {update} flags 69699 <UP,RUNNING,LOWER_UP>
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {newlink} index 103 address 5E:05:C7:7C:1A:E4 mtu 1500
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {newlink} index 103 operstate 0 <UNKNOWN>
<Guest641> Jun 11 15:30:44 beaglebone systemd-udevd[25902]: Using default interface naming scheme 'v240'.
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {add} route fe80:: gw :: scope 0 <UNIVERSE>
<Guest641> Jun 11 15:30:44 beaglebone systemd-udevd[25902]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
<Guest641> Jun 11 15:30:44 beaglebone playio-vpnc[25765]: INFO : Wait a VPN session is established...
<Guest641> Jun 11 15:30:46 beaglebone avahi-daemon[447]: Joining mDNS multicast group on interface vpn_bp.IPv6 with address fe80::5c05:c7ff:fe7c:1ae4.
<Guest641> Jun 11 15:30:46 beaglebone avahi-daemon[447]: New relevant interface vpn_bp.IPv6 for mDNS.
<Guest641> Jun 11 15:30:46 beaglebone avahi-daemon[447]: Registering new address record for fe80::5c05:c7ff:fe7c:1ae4 on vpn_bp.*.
<Guest641> Jun 11 15:30:46 beaglebone playio-vpnc[25765]: INFO : Wait a VPN IP is leased...
<Guest641> Jun 11 15:30:46 beaglebone playio-vpnc[25765]: INFO : Lease a new VPN IP...
<Guest641> Jun 11 15:30:46 beaglebone dhclient[25950]: Internet Systems Consortium DHCP Client 4.4.1
<Guest641> `Jun 11 15:30:42 beaglebone playio-vpnc[25765]: INFO : Start VPN Client if not yet running...
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {create} index 103 type 1 <ETHER>
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {update} flags 4098 <DOWN>
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {newlink} index 103 address D2:97:BA:73:B0:00 mtu 1500
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {newlink} index 103 operstate 2 <DOWN>
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {newlink} index 103 address 5E:05:C7:7C:1A:E4 mtu 1500
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {newlink} index 103 operstate 2 <DOWN>
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {update} flags 69699 <UP,RUNNING,LOWER_UP>
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {newlink} index 103 address 5E:05:C7:7C:1A:E4 mtu 1500
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {newlink} index 103 operstate 0 <UNKNOWN>
<Guest641> Jun 11 15:30:44 beaglebone systemd-udevd[25902]: Using default interface naming scheme 'v240'.
<Guest641> Jun 11 15:30:44 beaglebone connmand[15352]: vpn_bp {add} route fe80:: gw :: scope 0 <UNIVERSE>
<Guest641> Jun 11 15:30:44 beaglebone systemd-udevd[25902]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
<Guest641> Jun 11 15:30:44 beaglebone playio-vpnc[25765]: INFO : Wait a VPN session is established...
<Guest641> Jun 11 15:30:46 beaglebone avahi-daemon[447]: Joining mDNS multicast group on interface vpn_bp.IPv6 with address fe80::5c05:c7ff:fe7c:1ae4.
<Guest641> Jun 11 15:30:46 beaglebone avahi-daemon[447]: New relevant interface vpn_bp.IPv6 for mDNS.
<Guest641> Jun 11 15:30:46 beaglebone avahi-daemon[447]: Registering new address record for fe80::5c05:c7ff:fe7c:1ae4 on vpn_bp.*.
<Guest641> Jun 11 15:30:46 beaglebone playio-vpnc[25765]: INFO : Wait a VPN IP is leased...
<Guest641> this is a sys log
<zmatt> Guest641: don't do that ever again, pasting such a volume into chat
<zmatt> (I'm actually surprised you didn't get killed for spam by the server)
<zmatt> Guest641: to share multi-line text, use a paste service such as pastebin.com (and share the url here)
<zmatt> Guest641: I don't really have enough context to know what's going on, but my first guess would be that connman is interfering with what you're doing since that's what connman usually does, it assumes it is in full control over networking
CygniX has quit [Excess Flood]
<Guest641> zmatt thank you for your response. Sorry, this is first time I used libera chat, so it does not same other chat tool that mostly truncate text
CygniX has joined #beagle
<Guest641> this is pastebin for log
<Guest641> ya, ic. I already disable my vpn interface in `/etc/connman/main.conf`
<Guest641> like this `NetworkInterfaceBlacklist=SoftAp0,usb0,usb1,vpn_bp`
<zmatt> ok
<zmatt> curious that dhclient seems to have a successful lease at first
<Guest641> ya, then dhcp send arp to ensure this ip is unique. but suddenly, it return back `dhcpdecline`
<zmatt> I'm not really familiar with dhclient (for many years I've only used systemd-networkd for all my networking needs), a quick google says that dhclient runs some scripts and if they exit with failure it sends dhcpdecline
<zmatt> so maybe something is going wrong with running those scripts in the context of your service, for some reason
<zmatt> this is also a really strange message, I've never seen systemd say something like this:
<zmatt> Jun 11 15:44:37 beaglebone systemd[1]: playio-vpn.service: Supervising process 5239 which is not our child. We'll most likely not notice when it exits.
<Guest641> it is forking mode in systemd
<zmatt> i'm pretty sure that this message doesn't normally happen with forking mode
<Guest641> my vpn service will invoke vpnc binary and monitor it
<Guest641> Type=forking
<Guest641> Restart=on-failure
<Guest641> KillMode=control-group
<Guest641> WorkingDirectory=/app/vpnclient
<Guest641> PIDFile=/app/vpnclient/runtime/vpn.pid
<Guest641> like that
<zmatt> again, don't paste multi-line stuff into chat
<Guest641> ya, sorry bro
<zmatt> my guess is your PIDFile specifies a process which is not a direct child of systemd, hence it can't properly supervise when it exits. anyway, that's probably unrelated to your actual problem
<Guest641> ya, correct
<Guest641> this is a log
<Guest641> if I don't include invoking `dhclient` in unix service. After start vpn, I invoke it manually
<zmatt> I don't know what I'm looking at
<Guest641> it works fine, lease ipv4 then auto renew after half of expired time
<Guest641> Jun 11 16:10:59 beaglebone systemd[1]: Started playio-vpn.
<Guest641> Jun 11 16:12:30 beaglebone dhclient[29400]: Internet Systems Consortium DHCP Client 4.4.1
<zmatt> other than that it looks like your service is a bit of a mess ("Start VPN Client if not yet running" sounds like you're doing stuff that systemd normally does for you)
<Guest641> this is my tool logging. don't care about it too much. actually, my service system is like `vpnc manager` will manage and start `vpnc` connection depends on configuration
<zmatt> like I said, doing stuff systemd would normally do for you :P
<zmatt> but that's presumably unrelated to your problems (or maybe it isn't, since you said running dhclient manually does work)
<zmatt> anyway, based on a quick look at the dhclient source code, the only reason it will ever decline is if the script file (/sbin/dhclient-script by default but you can override that with -sf) exits with exit code 2
<zmatt> so that sounds like the best place to start investigating
<zmatt> Guest641: you could change the first line of that script from '#!/bin/bash' to '#!/bin/bash -x' to make bash log everything it's doing... though that'll be very spammy
<zmatt> (probably best to not modify the original but make a copy of it and use the -sf option of dhclient to point to it)
<zmatt> oh actually, it sends decline on any non-zero exit code in dhclient 4.4.1
<zmatt> never mind, debian patches that to only decline on exit code 2
<Guest641> coz, `vpnc` only work in daemon process so I need to wrapper by `manager` with `forking` mode. then it is quite strange for service `simple` mode
<zmatt> well, whatever you're doing is not working right, that systemd message is not normal
<Guest641> hmm, maybe. I will take a look for systemd message later.
<zmatt> Type=forking means your process invoked with ExecStart should spawn a child process, write its PID into the PIDFile, and then exit. this would cause this child process to become an orphan hence get reparented to pid 1 (i.e. systemd)
<zmatt> what systemd is saying is that the process listed in the PIDFile is, in fact, not a child of pid 1 at the moment your script exits
<zmatt> *has exited
Shadyman has quit [Quit: Leaving.]
<Guest641> https://pastebin.com/tWBaYmM4 not sure. but it is not orphan. because `vpnc` spawn 2 process. 1 is controller, 1 is main process. my service invoke controller then controller maintain main process. so quite tricky ;D
<zmatt> is 28021 a child of 28018 ? ("ps f -fe" is useful to see the process tree on your system)
<Guest641> ya
<zmatt> well then there's your problem, 28021 is supervised by 28018 and therefore cannot be supervised by systemd
<zmatt> you could remove the PIDFile from your service file to make systemd guess the MainPID, which should make it supervise the parent process (28018 in this case)
<zmatt> Restart=always is useless if systemd can't notice when a process exits
<Guest641> thanks, I will try your solution. my initial solution is watching pid file that is generated by 28018
<zmatt> yeah, that can't really work... you're trying to have a process be supervised by two different things (vpnclient's own manager process and systemd)
<zmatt> but anyway, this isn't related to your DECLINE issue
<Guest641> ya understood.
<Guest641> zmattt thank you for your tip: '#!/bin/bash -x'. One issue is after I used `dhclient`, an `anonymous` process changed my `/etc/resolv.conf`, so my device cannot found dns server anymore if I disconnect VPN connnection. initial configuration is `dnsmasq`: 127.0.0.1#53
<zmatt> connman
<zmatt> probably
<zmatt> connman expects to be in full control of /etc/resolv.conf
<zmatt> it also expects to be in full control of the default route
<zmatt> so if you're manually messing with either of those behind its back, you can expect problems
<zmatt> the solution is to either let connman take care of bringing up the interface, or replace connman by something else that's more tolerant of manual intervention
<zmatt> (I have an experimental procedure to replace connman by systemd-networkd here: https://pastebin.com/3tjj3v3R ... beware that it replaces the composite usb gadget by g_ether hence you won't have a serial console via usb anymore, if networking gets fucked up to the point of making the beaglebone unreachable then you'd need a serial console cable to get into the system to fix it)
<Guest641> ya, I hope I can replace it :') . but some devices are working in production mode. then I don't know if it is safe to replace it on the fly.
<zmatt> heh
<zmatt> that sounds like an... exciting... procedure.
<zmatt> anything is possible of course, I've deployed an update to our production beaglebones that prepared an entirely new set of files for the rootfs (fortunately our system is only a few hundred MB so plenty of free space on eMMC) and then replaced /boot/uEnv.txt by one that set the init= kernel parameter to an upgrade script (using statically linked busybox as shell) that removes the old files and moves ...
<zmatt> ...the new ones into place... carefully written to be as atomic and idempotent as possible
<zmatt> it worked perfectly but was still a bit scary
<zmatt> obviously did a lot of testing, including deliberate power failure during the upgrade process
calculu5 has quit [Ping timeout: 264 seconds]
calculus has joined #beagle
<Guest641> ya, ic. actually, I'm not sure what is device in production. many softwares, customize scripts and customization hardware for working with gpio. and we are migrating to raspberry for more stable. so if putting many efforts to redesign bbb image is not recommendation in my case. my boss will not like itXD
<zmatt> oof, sounds like a mess
<Guest641> thanks for your help. I will try to debug it more to see if I can find any workaround
calculus has quit [Ping timeout: 272 seconds]
calculus has joined #beagle
rob_w has quit [Quit: Leaving]
buzzmarshall has joined #beagle
Guest73 has joined #beagle
<Guest73> hello, wich architecture has the BeagleBone black?
vagrantc has joined #beagle
Guest73 has left #beagle [#beagle]
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
aswin has joined #beagle
Sheldor_abhi has joined #beagle
Sheldor_abhi has quit [Client Quit]
LetoThe2nd has quit [Quit: Connection closed for inactivity]
Sheldor_abhi has joined #beagle
Sheldor_abhi has quit [Client Quit]
Stanto_ has joined #beagle
buzzm has joined #beagle
dinuxbg_ has joined #beagle
zjason`` has joined #beagle
frostsno1 has joined #beagle
buzzmarshall has quit [*.net *.split]
mvaittin has quit [*.net *.split]
shoragan[m] has quit [*.net *.split]
jkridner[m] has quit [*.net *.split]
GenTooMan has quit [*.net *.split]
zjason` has quit [*.net *.split]
dinuxbg has quit [*.net *.split]
Stanto has quit [*.net *.split]
frostsnow has quit [*.net *.split]
Guest6137 has joined #beagle
Guest6137 has quit [Client Quit]
GenTooMan has joined #beagle
buzzm has quit [Quit: Konversation terminated!]
shoragan[m] has joined #beagle
avery_ has joined #beagle
outrageous has quit [Ping timeout: 272 seconds]
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #beagle
mvaittin has joined #beagle
GenTooMan has quit [Quit: Leaving]
GenTooMan has joined #beagle
m-atoms has joined #beagle
m-atoms has quit [Client Quit]
m-atoms has joined #beagle
jkridner[m] has joined #beagle
avery_ has quit [Quit: avery_]
avery_ has joined #beagle
avery_ has quit [Quit: avery_]
dinuxbg_ is now known as dinuxbg
calculu5 has joined #beagle
calculus has quit [Ping timeout: 272 seconds]
aswin has quit [Quit: leaving]
calculus has joined #beagle
calculu5 has quit [Ping timeout: 265 seconds]
calculus has quit [Remote host closed the connection]
calculus has joined #beagle