|
|
Post by barryk on Feb 17, 2018 12:12:15 GMT 1
Using BaCon 3.7.1
This fails:
zipc_event$="eth0"
outmsg_str$=CONCAT$(zipc_event$,"\n")
I found that if the string ends with ascii zero, the "\n" does not get appended.
CONCAT$ is getting ascii zero confused with numeric zero!
At first I thought that I must be making an error somewhere, so tested with different strings assigned to zipc_event$, yep, the "0" on the end upsets things.
|
|
|
|
Post by barryk on Feb 17, 2018 12:48:17 GMT 1
Same problem with:
outmsg_str$=zipc_event$&"\n"
|
|
|
|
Post by alexfish on Feb 17, 2018 13:22:50 GMT 1
Hi Barry
The Concat Requires the concat string to be in the scope `str= str + foo`
EG
zipc_event$="eth0"
outmsg_str$=CONCAT$(outmsg_str$,zipc_event$,"\n")
outmsg_str$=CONCAT$(outmsg_str$,"newline")
PRINT outmsg_str$
HTH
BR
Alex
|
|
|
|
Post by Pjot on Feb 17, 2018 16:05:58 GMT 1
Hi Barry,
Your code works perfectly fine for me though.
zipc_event$="eth0"
outmsg_str$=CONCAT$(zipc_event$,"\n")
PRINT "-", outmsg_str$, "-"
The output is as expected:
How did you conclude there is something going wrong here?
BR
Peter
|
|
|
|
Post by barryk on Feb 17, 2018 16:12:38 GMT 1
***PAUSE***
I will have to get back to you on this.
I wrote a little test program, and CONCAT$ worked fine.
But not in my bigger program. I will need to study the code some more, try and figure out why The "\n" refused to append to "eth0" but does to other strings, the same code.
|
|
|
|
Post by barryk on Feb 17, 2018 16:37:55 GMT 1
This doesn't make any sense to me. Peter, if you wouldn't mind taking a quick look at this. My latest pup_event_d.bac and binary (x86_64) is attached. This will write drive hotplug and network status to files, that scripts can wait on. Firstly, create these empty files: /tmp/pup_event_ipc/block_myapp /tmp/pup_event_ipc/network_myapp /tmp/pup_event_ipc/timeout1_myapp try the hotplugging... 1. run ./pup_event_d 2. plug in a usb drive 3. observe /tmp/pup_event_ipc/block_myapp has a new line. 4. Remove the drive 5. Again, another line appended to /tmp/pup_event_ipc/block_myapp That works as expected. Now test network connection... Assuming that your network connection is 'eth0' and pup_event_d still running 1. Bring the network down then up again typically that would be: ifconfig eth0 down ifconfig eth0 up 2. Observe change in /tmp/pup_event_ipc/network_myapp ..."eth0" gets appended to the file, but without the newline. Yet, it is exactly the same code as for the drive hotplugging! Ditto, look at /tmp/pup_event_ipc/timeout1_myapp, that gets appended to every 1 second, newline works there also. Attachments:pup_event_d.bac (7.19 KB)
pup_event_d (108.25 KB)
|
|
|
|
Post by barryk on Feb 17, 2018 16:44:12 GMT 1
P.S.
I know that taking out that USEC code to write to the file, and maybe just use Vovchik's APPEND, will probably fix it.
However, the code as it is should work, and I would very much like to know why it doesn't, instead of just giving up and coding it a different way.
|
|
|
|
Post by Pjot on Feb 17, 2018 21:00:00 GMT 1
Hi barry,
So I tried your program both in Linux Mint 18.2, and also in a XenialPup64 7.5 environment, but in both cases, I do not get any event when bringing up/down the ethernet interface.
The USB stick works though, and output is correct.
Is there any other setup I need to apply to make the eth0 event to work?
As a test, I added a PRINT at line 108:
PRINT buf FORMAT "===========%s=======\n"
...and this is showing me:
In other words, I do get events, also events on USB, but never for the network interface.
If you have suggestions on how to reproduce your problem, please let me know.
Best regards
Peter
|
|
|
|
Post by barryk on Feb 17, 2018 23:21:49 GMT 1
Hi Peter, thanks for looking into it.
When pup_event_d runs, it outputs to /tmp/pup_event_backend/net_ifs, with what it detects is your network interface.
In my case, the file just has "eth0".
If I bring down eth0, that file will become a blank line, bring eth0 up again, once again "eth0" appears in that file.
The program achieves this by examining /sys/class/net/*/dormant, where the "*" are the interfaces, "lo", "eth0", etc. If 'dormant' contains "0", then the interface is up.
It is possible that your distro is assigning some other name to the ethernet interface.
And if your computer has *two* interfaces up, I will have to think about that (it ignores "lo").
NOTE
Regarding the lack of network events from the kernel, I believe that a different kind of netlink socket is required. But, I don't know how to do that, so I have just polled /sys/class/net/*/dormant every one second.
...which is OK, as the program exits from the netlink socket every one second anyway, to generate a background "tick" (write to files /tmp/pup_event/timeout1_*).
|
|
|
|
Post by bigbass on Feb 18, 2018 7:13:24 GMT 1
Hello barryk
The why for just one small part of the code that caught my eye
clientfile_str$=CONCAT$("/tmp/pup_event_ipc/",(*ent1).d_name)
with the fix "(*ent1).d_name"
clientfile_str$=CONCAT$("/tmp/pup_event_ipc/","(*ent1).d_name")
'---a test
PRINT clientfile_str$
HTH in one small part
Joe
|
|
|
|
Post by Pjot on Feb 18, 2018 9:07:20 GMT 1
When pup_event_d runs, it outputs to /tmp/pup_event_backend/net_ifs, with what it detects is your network interface. In my case, the file just has "eth0". If I bring down eth0, that file will become a blank line, bring eth0 up again, once again "eth0" appears in that file. The 'pup_event_d.bac' program you have shared above, is apparently writing events into files at '/tmp/pup_event_ipc'. I have touched those files, but do not get events written to them for the network interface (only the USB interface). I am using the latest Puppy image from here in a fresh install. The program achieves this by examining /sys/class/net/*/dormant, where the "*" are the interfaces, "lo", "eth0", etc. If 'dormant' contains "0", then the interface is up. It is possible that your distro is assigning some other name to the ethernet interface. See above, the Puppy distribution actually uses 'eth0'. Regarding the lack of network events from the kernel, I believe that a different kind of netlink socket is required. But, I don't know how to do that, so I have just polled /sys/class/net/*/dormant every one second. ...which is OK, as the program exits from the netlink socket every one second anyway, to generate a background "tick" (write to files /tmp/pup_event/timeout1_*). Your program creates a PF_NETLINK socket, do I need to change some properties there? BR Peter |
|
|
|
Post by barryk on Feb 18, 2018 9:58:58 GMT 1
Peter,
Running XenialPup, what do you get when you run this in a terminal?:
grep -l '0' /sys/class/net/*/dormant
...that is the letter-l, and zero in the single-quotes.
Right now, I am using my baby laptop, connecting via wi-fi, and get this:
# grep -l '0' /sys/class/net/*/dormant
/sys/class/net/lo/dormant
/sys/class/net/wlan0/dormant
So, in my case, the active interface is 'wlan0'
|
|
|
|
Post by Pjot on Feb 18, 2018 10:08:23 GMT 1
This is my result:
|
|
|
|
Post by barryk on Feb 18, 2018 15:58:51 GMT 1
Ooooh, I see what might be wrong. The network section of the code is doing the same kind of low-level writing numeric-zero into a string, as I reported caused a segfault for the other thread.
No segfault this time, but the string might be getting messed up.
Um, I don't suppose it is possible to have a commandline option for the BaCon translator to turn off the string optimisation, just treat strings as plain C strings?
Otherwise, I will have to modify parts of the code. Probably need to check some other apps also.
Which reminds me, my 'popup' utility, developed awhile back, doesn't work properly when compiled recent BaCon. So, I am using a binary compiled with BaCon 2.0.3. Now I have a clue what to check for.
|
|
|
|
Post by Pjot on Feb 18, 2018 16:17:29 GMT 1
Dear barry, I already have fixed such situation for BaCon 3.7.2. If you need a snapshot or a final release for your purposes, then I can make one available for you, please let me know. Nevertheless, mixing pointers and strings is always very tricky, and literally asking for memory problems.  From the code you have shared, I can see many things which can are deprecated and can be improved or rewritten in a much nicer way. Over time, BaCon has evolved tremendously, thanks to the input of many users and forum members. So it might be good idea to refurbish your code, which still shows workarounds because of limitations in BaCon 2.x. I am happy to look at your code and provide suggestions for improvements. Feel free to come up with code parts for which you need a closer look. Best regards Peter |
|
