Re: [PATCH v2 2/2] tftp: ignore trailing garbage in the request
On Wed, Sep 3, 2014 at 11:06 PM, Aaro Koskinen aaro.koski...@iki.fi wrote:
On Wed, Sep 03, 2014 at 06:36:36PM +0200, Denys Vlasenko wrote:
On Mon, Sep 1, 2014 at 10:24 PM, Aaro Koskinen aaro.koski...@iki.fi wrote:
The firmware in some HP PA-RISC boxes is always sending fixed
512-byte requests, and sometimes there is some garbage at the end
which makes busybox to reject the request. Ignore any characters after
the last NUL.
How about this?
As you pointed out, I missed the short read possibility, and by
ignoring them that also made me to screw up my testing analysis
(should have checked with tcpdump) - the box is actually sending
*516-byte* requests. :-(
So following is still needed to current git to work with some PA-RISC:
diff --git a/networking/tftp.c b/networking/tftp.c
index 8e3b0a2..d9295c9 100644
--- a/networking/tftp.c
+++ b/networking/tftp.c
@@ -118,7 +118,7 @@ struct globals {
uint8_t error_pkt[4 + 32];
struct passwd *pw;
/* used in tftpd_main(), a bit big for stack: */
- char block_buf[TFTP_BLKSIZE_DEFAULT];
+ char block_buf[TFTP_BLKSIZE_DEFAULT + 4];
char block_buf_tail[1];
#if ENABLE_FEATURE_TFTP_PROGRESS_BAR
off_t pos;
@@ -811,7 +811,7 @@ int tftpd_main(int argc UNUSED_PARAM, char **argv)
) {
goto err;
}
- /* Some HP PA-RISC firmware always sends fixed 512-byte requests,
+ /* Some HP PA-RISC firmware always sends fixed 516-byte requests,
* with trailing garbage.
* Support that by not requiring NUL to be the last byte (see above).
* To make strXYZ() ops safe, force NUL termination:
Fixed in git, thanks!
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: killall behaviour
On Fri, Aug 29, 2014 at 7:01 PM, Harald Becker ra...@gmx.de wrote: This is suspicious. killall shall not kill both processes ... ./foobar cat /proc/19618/comm foobar cat /proc/19618/cmdline ./foobar cat /proc/19618/status Name: foobar ./hello cat /proc/19669/comm hello cat /proc/19669/cmdline ./hello cat /proc/19669/status Name: hello The names are different, so I can't see why killall foobar shall kill this hello. Looks like we have to investigate this further. killall matches by /proc/PID/exe too. Because some applets use a trick where they re-execute themselves by execve(/proc/self/exe). When you do that, /proc/PID/comm field gets set to string exe :( Thus, matching by comm will fail to find a process started this way. See find_pid_by_name.c: /* In Linux we have three ways to determine process name: 1. /proc/PID/stat has ...(name)..., among other things. It's so-called comm field. 2. /proc/PID/cmdline's first NUL-terminated string. It's argv[0] from exec syscall. 3. /proc/PID/exe symlink. Points to the running executable file. kernel threads: comm: thread name cmdline: empty exe: readlink fails executable comm: first 15 chars of base name (if executable is a symlink, then first 15 chars of symlink name are used) cmdline: argv[0] from exec syscall exe: points to executable (resolves symlink, unlike comm) script (an executable with #!/path/to/interpreter): comm: first 15 chars of script's base name (symlinks are not resolved) cmdline: /path/to/interpreter (symlinks are not resolved) (script name is in argv[1], args are pushed into argv[2] etc) exe: points to interpreter's executable (symlinks are resolved) If FEATURE_PREFER_APPLETS=y (and more so if FEATURE_SH_STANDALONE=y), some commands started from busybox shell, xargs or find are started by execXXX(/proc/self/exe, applet_name, params) and therefore comm field contains exe. */ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
