Bug 236930
| Summary: | contrib/bsnmp/snmpd: snmp_target wrong port | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Base System | Reporter: | Tatiana <t.ermakova> | ||||||
| Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Some People | CC: | ae, emaste, harti, ngie | ||||||
| Priority: | --- | Keywords: | needs-qa | ||||||
| Version: | 11.2-STABLE | Flags: | koobs:
mfc-stable12?
koobs: mfc-stable11? |
||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
@Tatiana Thank you for the report and patch Looks correct. Created attachment 203291 [details]
more correct patch
There was a mistake in the first patch
(In reply to Tatiana from comment #3) > Created attachment 203291 [details] > more correct patch > > There was a mistake in the first patch Yeah, but the idea is correct. :) A commit references this bug: Author: ae Date: Mon Apr 1 12:14:46 UTC 2019 New revision: 345763 URL: https://svnweb.freebsd.org/changeset/base/345763 Log: Correct a port number assignment. PR: 236930 MFC after: 1 week Changes: head/contrib/bsnmp/snmpd/trap.c LGTM as well! A commit references this bug: Author: ae Date: Mon Apr 8 11:53:38 UTC 2019 New revision: 346026 URL: https://svnweb.freebsd.org/changeset/base/346026 Log: MFC r345763: Correct a port number assignment. PR: 236930 Changes: _U stable/12/ stable/12/contrib/bsnmp/snmpd/trap.c A commit references this bug: Author: ae Date: Mon Apr 8 11:54:45 UTC 2019 New revision: 346027 URL: https://svnweb.freebsd.org/changeset/base/346027 Log: MFC r345763: Correct a port number assignment. PR: 236930 Changes: _U stable/11/ stable/11/contrib/bsnmp/snmpd/trap.c Fixed in head/, stable/12 and stable/11. Thanks! |
Created attachment 203290 [details] A fix-patch We've been trying to use smnp traps via snmp_target module and have encountered the situation, when big port number is not set correctly. I've managed to track this down in trap.c. Here is a simple example in c++, showing the problem. vector<uint8_t> address = {0x07, 0x06, 0x05, 0x04, 0x1a, 0x85}; unsigned short from_code = htons(address[4]) << 8 | htons(address[5]) << 0; unsigned short correct = htons(address[4] << 8 | address[5]); cout << ntohs(from_code) << ' ' << ntohs(correct) << endl; The output is: 133 6789 133 is 0x85, while 6789 is the expected result for {0x1a, 0x85}. I'm also attaching the patch that we'll be using in our project, so a reply/review would be great. Thanks in advance.