Activity for net-tools
-
Bernard Pidoux posted a comment on ticket #48
I agree that strlen(buff) is needed. However AX25_print() must return a char * In print function i = ptr[6] is used to get the callsign SSID value that can take from 0 to 15. Thus callsign have a variable length and IMHO strlen(buff) seems more correct and should be kept. --- a/lib/ax25.c 2023-06-29 11:16:10.000000000 +0200 +++ b/lib/ax25.c 2024-09-02 00:22:10.909106399 +0200 @@ -49,7 +49,7 @@ extern struct aftype ax25_aftype; static const char AX25_print(const char ptr) { - static char buff[8];...
-
Mike Frysinger posted a comment on ticket #48
thanks, i thought the loop always wrote out 6 bytes followed by the NUL, but didn't read it closely enough.
-
Bernd Eckenfels posted a comment on ticket #48
i dont think it works without strlen the first part can be up to 6, in the example from Bernard it is only 5. we could exit the loop and use i instead of strlen, though.
-
diff -pruN a/lib/ax25.c b/lib/ax25.c --- a/lib/ax25.c 2023-06-29 11:16:10.000000000 +0200 +++ b/lib/ax25.c 2024-09-01 17:23:33.411623086 +0200 @@ -49,7 +49,7 @@ extern struct aftype ax25_aftype; static const char AX25_print(const char ptr) { - static char buff[8]; + static char buff[10]; int i; for (i = 0; i < 6; i++) { @@ -60,7 +60,7 @@ static const char *AX25_print(const char buff[6] = '\0'; i = ((ptr[6] & 0x1E) >> 1); if (i != 0) - sprintf(&buff[strlen(buff)], "-%d", i); + sprintf(buff + 6, "-%d",...
-
Mike, I patched ax25.c and it compiles and works perfectly. Thanks a lot for your suggestions. I learned something ! ./ifconfig ax0 ax0: flags=67<up,broadcast,running> mtu 253 ax25 F6BVP txqueuelen 10 (AMPR AX.25) RX packets 13 bytes 285 (285.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 100 bytes 3246 (3.1 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0</up,broadcast,running>
-
increasing buffer to 9 bytes is insufficient. the sprintf call can write up to 10 bytes. i = ((ptr[6] & 0x1E) >> 1); can be 2 digits which means the sprintf will write 4 bytes and since it always does it at offset 6, we need 10. would be good to simplify the sprintf code a little too while at it. - sprintf(&buff[strlen(buff)], "-%d", i); + sprintf(buff + 6, "-%d", i);
-
Bug solved ! Increasing buff[] size by one solved the issue while keeping -O2 optimize compile option that is probably over optimizing strlen ! Here is diff file : --- a/lib/ax25.c 2023-06-29 11:16:10.000000000 +0200 +++ b/lib/ax25.c 2024-08-30 12:40:37.989684153 +0200 @@ -49,7 +49,7 @@ extern struct aftype ax25_aftype; static const char *AX25_print(const char *ptr) { - static char buff[8]; + static char buff[9]; int i; for (i = 0; i < 6; i++) { By the way : Linux Ubuntu-2404 6.8.0-41-generic #41-Ubuntu...
-
Hi, In bug submission it is recommanded to provide application version. This is what is shown when command line - -version is : ./ifconfig --version net-tools 3.14-alpha
-
Where : (gdb) where #0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44 #1 __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 #2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) at ./nptl/pthread_kill.c:89 #3 0x00007ffff7c4526e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #4 0x00007ffff7c288ff in __GI_abort () at ./stdlib/abort.c:79 #5 0x00007ffff7c297b6 in __libc_message_impl...
-
bernard@Ubuntu-2404:~$ ifconfig --version net-tools 3.14-alpha bernard@Ubuntu-2404:~$
-
Proof : bernard@Ubuntu-2404:~$ ifconfig ax0 ax0: flags=67<up,broadcast,running> mtu 253 ax25 F6BVP-12 txqueuelen 10 (AMPR AX.25) RX packets 379 bytes 14816 (14.4 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 13999 bytes 991325 (968.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0</up,broadcast,running>
-
Bug solved ! Increasing buff[] size by one solved the issue while keeping -O2 optimize compile option that is probably over optimizing strlen ! Here is diff file : --- a/lib/ax25.c 2023-06-29 11:16:10.000000000 +0200 +++ b/lib/ax25.c 2024-08-30 12:40:37.989684153 +0200 @@ -49,7 +49,7 @@ extern struct aftype ax25_aftype; static const char AX25_print(const char ptr) { - static char buff[8]; + static char buff[9]; int i; for (i = 0; i < 6; i++) { By the way : Linux Ubuntu-2404 6.8.0-41-generic #41-Ubuntu...
-
po: Add Georgian translation
-
slattach: Support tty speeds 230400 to 4000000.
-
statistics: Show recvbuf/sendbuf errors for IPv6+UDP.
-
statistics: Add checksum errors for UDP.
-
fix minor miss in route man (fr_FR)
-
fix typos in netstat man (de_DE)
-
GitHub committed [116b26] on Code
mii-tool.c removed dead reference links from comment
-
GitHub committed [081a8a] on Code
mii-tool.c fix OUI alternative interpretation bit pattern
-
fix decoding of MII vendor ids
-
f4klo posted a comment on ticket #48
<meta http-equiv="content-type" content="text/html; charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8">Hi,In bug submission it is recommanded to provide application version.This is what is shown when command line - -version is :./ifconfig --versionnet-tools 3.14-alphanet-tools 3.14-alpha 73 de Bernard F6BVP / AI7BG-- मेरे बहुत-से शौक़ हैंj'ai beaucoup de passe-tempsI have many hobbieshttp://f4klo.ampr.org/http://radiotelescope-lavillette.fr/au-jour-le-jour/(use Google...
-
Removing -O2 in makefile solved the bug. I don't see why. ./ifconfig ax0 ax0: flags=67<up,broadcast,running> mtu 253 ax25 F6BVP-12 txqueuelen 10 (AMPR AX.25) RX packets 23 bytes 529 (529.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 425 bytes 7868 (7.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0</up,broadcast,running>
-
looks like the snprintf in ax should be easy tonfund with your contributed info, 2ill let you know. is that some malicious host or just regilsr enabled kernel? has it aftually such hardware? maybe you can share the related proc files, meanwhile? thanks ait for reporting!
-
Correction : gdb --args ./ifconfig rose0 is OK! (gdb) run Starting program: /home/bernard/Téléchargements/net-tools-code-20a78e06a69bd9b6b4e15468201d5d3aa9c395db/ifconfig rose0 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". rose0: flags=193<up,running,noarp> mtu 251 rose 2080835201 txqueuelen 1000 (AMPR ROSE) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped...
-
looks like the snprintf in ax should be easy tonfund with your contributed info, 2ill let you know. is that some malicious host or just regilsr enabled kernel? has it aftually such hardware? maybe you can share the related proc files, meanwhile? thanks ait for reporting - whats the 3.14 refering to?
-
Where : (gdb) where 0 __pthread_kill_implementation (no_tid=0, signo=6, threadid=<optimized out="">) at ./nptl/pthread_kill.c:44</optimized> 1 __pthread_kill_internal (signo=6, threadid=<optimized out="">) at ./nptl/pthread_kill.c:78</optimized> 2 __GI___pthread_kill (threadid=<optimized out="">, signo=signo@entry=6) at ./nptl/pthread_kill.c:89</optimized> 3 0x00007ffff7c4526e in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 4 0x00007ffff7c288ff in __GI_abort () at ./stdlib/abort.c:79...
-
ifconfig buffer overflow (net-tools 3.14-alpha)
-
Bernd committed [20a78e] on Code
Revert "sscanf pattern is %Lu not %llu for long long unsigned byte counters."
-
WHR posted a comment on merge request #13
The title should be: netstat(8) treats port numbers in /proc/net/ipx/socket in network byte order casuing incorrect port numbers being displayed on little-endian systems However I couldn't find a way to edit it.
-
Extend maximum fetched hardware address length and update related man pages
-
Helge Kreutzmann posted a comment on ticket #47
Hello Mike, hello Bernd, how do you suggest to proceed? I really love to resolve the file conflicts with manpages-l10n, and I'm glad to help you with po4a integration; however, your last response is from September 2022, about half a year ago, so I'm unsure what to do next. Greetings Helge
-
netstat(8) treats port numbers in /proc/net/ipx/socket in host byte order casuing incorrect port numbers being displayed on little-endian systems
-
Hello Mike, hello Bernd, how do we want to proceed? Thanks for your reply.
-
Hello Mike, hello Bernd, ping? Do you think this can be integrated in principle? Please let me know any issues you have. Also if you approve the general idea, translation teams can work on updating their text (can happen in parallel to the inclusion). Thanks!
-
Hello Mike, hello Bernd, did you have a chance to review the latest version? Any further shortcomings or questions? If you agree with the principles, I suggest I review the original man pages (taking into account Bug 41) and afterwards initiate a call for updated translations to the French and Brazilian Portuguese Teams (I would handle German myself). Since by design my patch is non-intrusive (i.e. does not change anything unless explicitly called) it would be good to commit it and then everyone...
-
Hello Mike, I added the requested target(s). They are called "update-po" and "pot". The first updates the po files (those used by translators), the second one updates the pot file and is probably not needed, but might help testing. I also worked on the German translation a little bit and prepared the fr.po and pt_BR.po as much as I could (using strings from manpages-l10n). Please review. Once you agree with the fundamental idea I can request the French and Brazilian Portugese teams to update their...
-
Hello Mike, currently, the build target will not be called automatically, since up to now nothing needed to be done for "building". So in fact, it is not already the case. But to make this more clear, I can of course rename the make target, no problem. For review: This is all new code except that I copied the man/Makefile and made some small additions. Hence the diff is empty, i.e. nothing to compare. So simply extract my tarball and look at the (new) code. Comparing the two make files yields: ---...
-
Hello Mike, currently, the build target will not be called automatically, since up to now nothing needed to be done for "building". So in fact, it is not already the case. But to make this more clear, I can of course rename the make target, no problem. For review: This is all new code except that I copied the man/Makefile and made some small additions. Hence the diff is empty, i.e. nothing to compare. So simply extract my tarball and look at the (new) code. Comparing the two man pages yields: ---...
-
patches are easier to review. can you just use normal git diff or git am output ? process-wise, i would expect this target to be something developers have to invoke manually, not something that would be automatic. that way it wouldn't show up for random non-net-tools developers, just people trying to e.g. build from git. some sort of make update-translations or something. and we'd update our release docs to include that step before doing a final release.
-
Hello Bernd, hello other developers, Essentially it is ready now (except for some small bugs, of course :-)) I attached it. I can be extracted in man/ How it works: I added the generation part as sub directory to man/ and extended man/Makefile such that the localized man pages are generated, updated, cleaned etc. after the static translated man pages. This is supposed to be temporary, in the long run the static ones should be removed. Please note, that for clarity, I copied Makefile to Makefile.new....
-
Yes, the translations themselves come from contributors. However, currently they cannot detect (easily) if you changed the original. With po4a and the po format it is straightforward. However, po4a is nothing to be used by translators. For this system to work, your project needs to include po4a and ship the po(t) files. Then a translator of a new language provides you with the correct po file (e.g. fi.po for Finnish) and you simply drop it in the right place and the next time the package is built,...
-
hello Helge, we are not doing translations ourself, we just merged request from helpful contributors. how they do the translation or corrections I am not sure. They might have used po4a before. They can always run the tool themself. but if you think we can aid that process with an addition to the makefile, i am all for it. i will merge such a patch (i am just not planning to read up on this translation tool. keep in mind net-tools is mostly obsolete these days.) but i think that was not the point...
-
Hello Bernd, as far as I can see Debian is shipping your English man pages and your translated man pages. As do other distributions as well. So while I'm taking the example of Debian, there is nothing specific in respect to Debian here. For me, having you handle the translations alongside your English version is a good option. As translations get outdated over time (as you work on the English original), you need a tool to manage the translations and provide yourself, your translators and your users...
-
that one makes sense though i think. it's a diff tool provided by a diff project with diff command line options. afaik, they maintain their own translations too. that would be a good argument for keeping translations of hostname man pages in net-tools itself. which i guess would extrapolate to all man pages we have (and intend on "keeping" vs moving to the man-pages project).
-
while searching around looks like old init ecripts used the file to prepopulate arp tables, not sure of this is a good thing but since RH issued an errata for it... https://bugzilla.redhat.com/show_bug.cgi?id=696788 (but thats very old rhel6)
-
while seqrching around looks like old init ecripts used the file to prepopulate arp tables, not sure of this is a good thing but since RH issued an errata for it... https://bugzilla.redhat.com/show_bug.cgi?id=696788 (but thats very old rhel6)
-
yes good point (just changed my domment). i am not sure but i thought wireshark, tcpdump (ibm manpage says so, linux manpage does not) and arpd also use it.
-
just to mention another conflict, the hostname package has its own manpage, its a fork of net-tools.
-
yes good point (just chsnged my domment)
-
oh just a comment, given that sooner or later net-tools is optional package it makes sense to move some of tne more generic manpages out of it. i dont know where they would go, is the manpwges project used for those base pages? in that case ether(5) feel free to adopt them, i would then delete all languages from this package. however the tools specific pages should remain. This is asuming other tools besides arp(8) would use the file, not really sure about that. they should then be added as links...
-
is /etc/ethers used by anything other than the net-tools arp daemons ? i wasn't sure if it was really generic enough to consider shifting to the upstream man-pages project.
-
oh just a comment, given that sooner or later net-tools is optional package it makes sense to move some of tne more generic manpages out of it. i dont know where they would go, is the manpwges project used for those base pages? in that case ether(5) feel free to adopt them, i would then delete all languages from this package. however the tools specific pages should remain.
-
Hello, I don’t really have a plan or idea about translations. We regularly accept pull requests but have no means to verify or refresh them. If you have a better source in Debian feel free toexclude those files from the package. However i would feel the natural place to keep those contributions would be in the upstream project. So if you have a fixed ether.5 please send the patch. same is probably true for adding po4a (but i dont know what it is and what it is used for) Gruss Bernd
-
if the canonical ethers(5) is maintained in net-tools, then it makes sense to include translations in here too
-
Clarifying handling of localized man pages
-
Tomasz Kłoczko posted a comment on ticket #46
not everyone agrees that pure web interfaces are better than mailing lists You can ioterract with github dicussions olnly over email as well.
-
I maintain a clone of it on GitHub here: https://github.com/ecki/net-tools
-
For a new and active project I would probably change it, but in this maintenance mode i would not expect much discussions and dont want to split the communication. we do accept PR and issues on github (and i pushed the missing commits).
-
not everyone agrees that pure web interfaces are better than mailing lists
-
guthub discussions are way better bacuae you can way eadier eneble/disable flow of of comments from entire dicussion or only exact thread, Other thing is that whatever is mentioned in discussion like issue ticket or PR it is automatically linked. github as well links issues/PRs/discussions from other repos if they will be mentioned so it is easier to work if some sunbject is streaching across multipole repos. Trust me .. it is rral value to move away from mailing list. Guthub automatically sends...
-
we have a mailing list already if you want to discuss things
-
Correction: sf.net has 3 more commits than github.
-
Just checked and looks like in sf.net repo there afe still two more commits rhan in git. As already id created git repo on github IMO it woud be better to sync what is in github and make it primary. Other thing is that in github is possible eneble dicussions tab (you can find it in repo settings).
-
Thank you :)
-
Please migrate git repo to gitlab/github
-
Please migrate git repo to gitlab/githun
-
Hello, I maintain a clone of it o GitHub here: https://github.com/ecki/net-tools Gruss Bernd
-
</div><div><div> <div dir="ltr">Hello,</div><div dir="ltr"><br></div><div dir="ltr">I maintain a clone of it o GitHub here: <a rel="noreferrer noopener" href="https://github.com/ecki/net-tools">https://github.com/ecki/net-tools</a></div><div dir="ltr"><br></div><div dir="ltr">Gruss</div><div dir="ltr">Bernd</div><div id="ms-outlook-mobile-signature"><div style="direction:ltr">-- </div><div style="direction:ltr">http://bernd.eckenfels.net</div></div> </div> Von: bugs@net-tools.p.re.sourceforge.net...
-
Please migrate git repo to gitlab/githun
-
okiedokie, pushed that fix https://sourceforge.net/p/net-tools/code/ci/4030929bb6f3ee6f465c76869d7a49424df45d9e
-
Flags short form not uniq in interface output
-
Mike Frysinger committed [403092]
interface: change pointopoint short flag from P to p
-
Can’t remember I think I was inspired by BSD tools but not sure. I would agree to change pointtopoint, because PROMISC might be more security critical (even when the linked patch modified it from M to P …)
-
</div><div><div> <div dir="ltr"><span style="caret-color:rgb(0, 0, 0);background-color:rgb(255, 255, 255);display:inline !important">Can’t remember I think I was inspired by BSD tools but not sure. I would agree to change pointtopoint, because PROMISC might be more security critical (even when the linked patch modified it from M to P …)</span><br></div> <div id="ms-outlook-mobile-signature"><div><br></div><div>Gruss</div><div dir="ltr">Bernd</div><div style="direction:ltr">-- </div><div style="direction:ltr">http://bernd.eckenfels.net</div></div>...
-
Flags short form not uniq in interface output
-
this bug has been around for over 21 years ;). added via https://sourceforge.net/p/net-tools/code/ci/942d4debc340b0ea039483301088ff5e667009bf i don't know how the short flags were picked and whether they're related to anything else (like a command line option). if they're not, easiest thing is prob to change pointtopoint to lowercase p. i can't find any such relationship in the tree ...
-
Mike Frysinger committed [eb2653]
shrink some code
-
Peter Radisson created ticket #45
Flags short form not uniq
-
Lockywolf created merge request #12
Format ipv6 addresses unambiguously.
-
Joe Jamison posted a comment on ticket #32
I know this is an esoteric bug, but in 2.6+ kernel versions, the /proc pathnames have changed. The formats are still the same. I got it to work by updating _PATH_PROCNET_ATALK to "/proc/net/atalk", and _PATH_PROCNET_ATALK_ROUTE to "/proc/net/atalk/route". (./lib/pathnames.h, lines 41 and 58). I also updated ./lib/ddp.c line 62 from "/proc/net/appletalk" to _PATH_PROCNET_ATALK. ./lib/ddp_gr.c already used the macro, so no update was necessary. For testing, I used netatalk-2.2.6. You have to patch...
-
robertsong posted a comment on ticket #44
hi, mike, thank you for you reply. name : Robert Song, e-mail address : robertsong.japan@gmail.com Best Regards Mike Frysinger vapier@users.sourceforge.net 于2021年4月22日周四 下午10:22写道： patch looks fine, but can you provide your name & e-mail address for credit ? [bugs:#44] https://sourceforge.net/p/net-tools/bugs/44/ entry Iptab not sorted* Status: open Group: NEXTGEN Created: Thu Apr 22, 2021 01:09 PM UTC by robertsong Last Updated: Thu Apr 22, 2021 01:09 PM UTC Owner: nobody Attachments: Iptab_sort_fix.patch...
-
entry Iptab not sorted
-
thanks, merged in commit dfc41e0675179912d4425672b90cac8e45b3dab4!
-
thanks, merged in commit dfc41e0675179912d4425672b90cac8e45b3dab4!
-
thanks, merged!
-
Mike Frysinger committed [dfc41e]
Iptab: sort entries
-
hi, mike, thank you for you reply. name : Robert Song, e-mail address : robertsong.japan@gmail.com Best Regards
-
patch looks fine, but can you provide your name & e-mail address for credit ?
-
entry Iptab not sorted
-
tdussa created merge request #11
-
Lam Thai created ticket #43
netstat -s output
-
GitHub committed [6cd515]
Add CRC and Frame errors to RX-ERR counter (#11)
-
Fix typo in french man
-
Mike Frysinger committed [2fa151]
bump version for git & next release
-
this might be related to this github issue and a gentoo patch (for musl?) https://github.com/ecki/net-tools/issues/14
-
net-tools 2.10 released
-
no new release for long time
-
net-tools-2.10 is now available!
-
Mike Frysinger committed [54bbf6]
cvsignore: punt ancient VCS file
1 >