diff for snmpd agentx.c
This brings snmpd agentx.c closer to relayd agentx.c.
In the remaining delta, I am not sure if the pdu context code should be removed
from the snmpd version or added to the relayd version.
Anyway, this is one step closer.
Ok?
Rob
Index: agentx.c
===
RCS file: /cvs/src/usr.sbin/snmpd/agentx.c,v
retrieving revision 1.12
diff -u -p -r1.12 agentx.c
--- agentx.c14 Feb 2018 12:43:07 - 1.12
+++ agentx.c10 Jun 2018 16:59:01 -
@@ -18,12 +18,8 @@
#include
#include
#include
-#include
#include
-#include
-
-#include
#include
#include
#include
@@ -217,9 +213,14 @@ snmp_agentx_response(struct agentx_handl
{
struct agentx_response_data resp;
- if (snmp_agentx_read_response(pdu, &resp) == -1)
+ if (snmp_agentx_read_raw(pdu, &resp, sizeof(resp)) == -1)
return (-1);
+ if (!snmp_agentx_byteorder_native(pdu->hdr)) {
+ resp.error = snmp_agentx_int16_byteswap(resp.error);
+ resp.index = snmp_agentx_int16_byteswap(resp.index);
+ }
+
h->error = resp.error;
if (resp.error != AGENTX_ERR_NONE)
return (-1);
@@ -227,20 +228,6 @@ snmp_agentx_response(struct agentx_handl
return (0);
}
-int
-snmp_agentx_read_response(struct agentx_pdu *pdu, struct agentx_response_data
*resp)
-{
- if (snmp_agentx_read_raw(pdu, resp, sizeof(*resp)) == -1)
- return (-1);
-
- if (!snmp_agentx_byteorder_native(pdu->hdr)) {
- resp->error = snmp_agentx_int16_byteswap(resp->error);
- resp->index = snmp_agentx_int16_byteswap(resp->index);
- }
-
- return (0);
-}
-
/*
* Read the response PDU for an open operation.
*/
@@ -341,7 +328,7 @@ snmp_agentx_recv(struct agentx_handle *h
if (h->r == NULL) {
if ((h->r = snmp_agentx_pdu_alloc()) == NULL)
return (NULL);
- h->r->datalen = 0; /* XXX -- force this for receive
buffers */
+ h->r->datalen = 0; /* XXX force this for receive buffers */
}
pdu = h->r;
@@ -1038,7 +1025,7 @@ snmp_oid2string(struct snmp_oid *o, char
bzero(buf, len);
for (i = 0; i < o->o_n; i++) {
- snprintf(str, sizeof(str), "%d", o->o_id[i]);
+ snprintf(str, sizeof(str), "%u", o->o_id[i]);
strlcat(buf, str, len);
if (i < (o->o_n - 1))
strlcat(buf, ".", len);
Index: control.c
===
RCS file: /cvs/src/usr.sbin/snmpd/control.c,v
retrieving revision 1.42
diff -u -p -r1.42 control.c
--- control.c 21 Apr 2017 13:50:23 - 1.42
+++ control.c 10 Jun 2018 16:59:01 -
@@ -537,7 +537,7 @@ control_dispatch_agentx(int fd, short ev
struct agentx_varbind_hdrvbhdr;
struct ber_element **elm, **iter;
- if (snmp_agentx_read_response(pdu, &resp) == -1) {
+ if (snmp_agentx_read_raw(pdu, &resp, sizeof(resp)) ==
-1) {
msg->sm_error = SNMP_ERROR_GENERR;
goto dispatch;
}
Index: snmp.h
===
RCS file: /cvs/src/usr.sbin/snmpd/snmp.h,v
retrieving revision 1.14
diff -u -p -r1.14 snmp.h
--- snmp.h 11 Jun 2015 18:49:09 - 1.14
+++ snmp.h 10 Jun 2018 16:59:01 -
@@ -369,7 +369,6 @@ struct agentx_handle *
struct agentx_handle *
snmp_agentx_fdopen(int, char *, struct snmp_oid *);
intsnmp_agentx_response(struct agentx_handle *, struct agentx_pdu *);
-intsnmp_agentx_read_response(struct agentx_pdu *, struct
agentx_response_data *);
intsnmp_agentx_open_response(struct agentx_handle *, struct agentx_pdu *);
struct agentx_pdu *
snmp_agentx_open_pdu(struct agentx_handle *, char *descr,
Odd Public WiFi breaks dhclient(8) but works for iPhone (Fix!)
On Sat, Jun 09, 2018 at 02:10:09PM +0200, Claudio Jeker wrote:
> On Sat, Jun 09, 2018 at 01:31:20PM +0200, Martin Pieuchot wrote:
> > On 08/06/18(Fri) 18:06, Kenneth R Westerback wrote:
> > > Testing at the alternate DHCP lab (the one that serves beer) I find
> > > that its wifi gives me the lease
> > >
> > > lease {
> > > fixed-address 10.112.38.73;
> > > next-server 0.0.0.0;
> > > option subnet-mask 255.255.255.0;
> > > option routers 10.112.33.1;
> > > option domain-name-servers 63.250.111.34,63.250.111.35,8.8.8.8;
> > > option dhcp-lease-time 14400;
> > > option dhcp-message-type 5;
> > > option dhcp-server-identifier 10.112.38.1;
> > > option dhcp-renewal-time 7200;
> > > option dhcp-rebinding-time 12600;
> > > option dhcp-client-identifier 1:9c:4e:36:d6:7e:f8;
> > > epoch 1528494503;
> > > renew 5 2018/06/08 23:48:23 UTC;
> > > rebind 6 2018/06/09 01:18:23 UTC;
> > > expire 6 2018/06/09 01:48:23 UTC;
> > > }
> > >
> > > See the problem? If so, skip the next paragraph.
> > >
> > > Note that I get an address of 10.112.38.73/24 and a default route of
> > > 10.112.33.1. When dhclient attempts to add the default route our stack
> > > rejects the attempt as 10.112.33.1 is unreachable! Not only does this
> > > mean the outside world is unreachable, /etc/resolv.conf will not be
> > > updated because the wifi interface will not own the default route, and
> > > thus DNS will not work!
> > >
> > > As this particular DHCP testing facility not only serves beer but
> > > provides paper table coverings and a basket of crayons (although I had
> > > to surrender my blue crayon to a young artist at the next table) I
> > > was able to do some complex bit calculations and determine that
> > > 255.255.240.0 would put the default route and the address in the same
> > > subnet. I therefore added
> > >
> > > supersede subnet-mask 255.255.240.0;
> > >
> > > to my dhclient.conf and viola (sic)! I had net.
> > >
> > > Checking the iPhone I see the same issue, but the iPhone does connect
> > > to the network without manual magic. A little birdie told me that IOS
> > > may be playing games with the provided subnet mask to ensure the
> > > default route is reachable.
> >
> > Can you check what is the configured address' mask on iOS?
> >
> > > I'm wondering if this auto subnet-mask trimming to ensure the default
> > > route would be reachable is worthwhile adding? Or if it might break
> > > more situations than it fixes.
> >
> > I'd say that there's nothing more frustrating than having a non functional
> > network connection after having used dhclient(8). So I doubt we're going
> > to break anything. However I'm wondering what other OSes are doing because
> > I'm not sure we should work around broken configs :)
>
> Isn't this similar to the google cloud dhcp mode where you get a /32 host
> IP and a gateway (which is not part of the the /32 obviously).
> IIRC this is what some other systems do more or less.
> I think a trick could be to insert the gateway as a /32 cloning route then
> arp would resolve the gateway which I assume works just fine. Now how to
> do this exactly is an excercise for the reader ;)
>
>
> --
> :wq Claudio
Turning Claudio's idea into a diff gives the diff below.
Testing at DHCP Lab B gives a routing table
Internet:
DestinationGatewayFlags Refs Use Mtu Prio Iface
Label
default10.112.33.1GS29 187 -12 iwn0
224/4 127.0.0.1 URS0 23 32768 8 lo0
10.112.33/24 10.112.38.215 CS 10 -12 iwn0
10.112.33.1a4:6c:2a:5e:8a:de HLch 15 -11 iwn0
10.112.38/24 10.112.38.215 Cn 09 - 8 iwn0
10.112.38.215 9c:4e:36:d6:7e:f8 UHLl 0 35 - 1 iwn0
10.112.38.255 10.112.38.215 Hb 01 - 1 iwn0
127/8 127.0.0.1 UGRS 00 32768 8 lo0
127.0.0.1 127.0.0.1 UHhl 12 32768 1 lo0
x230$
and a resolv.conf
# Generated by iwn0 dhclient
nameserver 63.250.111.34
nameserver 63.250.111.35
nameserver 8.8.8.8
lookup file bind
family inet4
after getting the lease
lease {
fixed-address 10.112.38.215;
next-server 0.0.0.0;
option subnet-mask 255.255.255.0;
option routers 10.112.33.1;
option domain-name-servers 63.250.111.34,63.250.111.35,8.8.8.8;
option dhcp-lease-time 14400;
option dhcp-message-type 5;
option dhcp-server-identifier 10.112.38.1;
option dhcp-renewal-time 7200;
option dhcp-rebinding-time 12600;
option dhcp-client-identifier 1:9c:4e:36:d6:7e:f8;
epoch 1528651658;
renew 0 2018/06/10 19:27:38 UTC;
rebind 0 2018/06/10 20:57:38 UTC;
expire 0 2018/06/10 21:27:38 UTC;
}
And it works! As sending this email proves. :-)
Now, whether it is a good idea ... none of the Google incantations I
used turned up evidence that this is a
Re: Odd Public WiFi breaks dhclient(8) but works for iPhone (Fix!)
Another approach is to extend subnet by decreasing mask to include router to client subnet. I.e.: 10.112.38.73/16. dhcp-options(5), RFC-2132: "The router option specifies a list of IP addresses for routers on the client's subnet." >From my point of view dhcp server in your example violates RFC, it is misconfigured and should not work at all. -- Sent from: http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-tech-f151936.html
Re: diff for snmpd agentx.c
Rob Pierce(r...@2keys.ca) on 2018.06.10 13:25:23 -0400:
> This brings snmpd agentx.c closer to relayd agentx.c.
>
> In the remaining delta, I am not sure if the pdu context code should be
> removed
> from the snmpd version or added to the relayd version.
>
> Anyway, this is one step closer.
>
> Ok?
ok
> Rob
>
> Index: agentx.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/agentx.c,v
> retrieving revision 1.12
> diff -u -p -r1.12 agentx.c
> --- agentx.c 14 Feb 2018 12:43:07 - 1.12
> +++ agentx.c 10 Jun 2018 16:59:01 -
> @@ -18,12 +18,8 @@
> #include
> #include
> #include
> -#include
> #include
>
> -#include
> -
> -#include
> #include
> #include
> #include
> @@ -217,9 +213,14 @@ snmp_agentx_response(struct agentx_handl
> {
> struct agentx_response_data resp;
>
> - if (snmp_agentx_read_response(pdu, &resp) == -1)
> + if (snmp_agentx_read_raw(pdu, &resp, sizeof(resp)) == -1)
> return (-1);
>
> + if (!snmp_agentx_byteorder_native(pdu->hdr)) {
> + resp.error = snmp_agentx_int16_byteswap(resp.error);
> + resp.index = snmp_agentx_int16_byteswap(resp.index);
> + }
> +
> h->error = resp.error;
> if (resp.error != AGENTX_ERR_NONE)
> return (-1);
> @@ -227,20 +228,6 @@ snmp_agentx_response(struct agentx_handl
> return (0);
> }
>
> -int
> -snmp_agentx_read_response(struct agentx_pdu *pdu, struct
> agentx_response_data *resp)
> -{
> - if (snmp_agentx_read_raw(pdu, resp, sizeof(*resp)) == -1)
> - return (-1);
> -
> - if (!snmp_agentx_byteorder_native(pdu->hdr)) {
> - resp->error = snmp_agentx_int16_byteswap(resp->error);
> - resp->index = snmp_agentx_int16_byteswap(resp->index);
> - }
> -
> - return (0);
> -}
> -
> /*
> * Read the response PDU for an open operation.
> */
> @@ -341,7 +328,7 @@ snmp_agentx_recv(struct agentx_handle *h
> if (h->r == NULL) {
> if ((h->r = snmp_agentx_pdu_alloc()) == NULL)
> return (NULL);
> - h->r->datalen = 0; /* XXX -- force this for receive
> buffers */
> + h->r->datalen = 0; /* XXX force this for receive buffers */
> }
> pdu = h->r;
>
> @@ -1038,7 +1025,7 @@ snmp_oid2string(struct snmp_oid *o, char
> bzero(buf, len);
>
> for (i = 0; i < o->o_n; i++) {
> - snprintf(str, sizeof(str), "%d", o->o_id[i]);
> + snprintf(str, sizeof(str), "%u", o->o_id[i]);
> strlcat(buf, str, len);
> if (i < (o->o_n - 1))
> strlcat(buf, ".", len);
> Index: control.c
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/control.c,v
> retrieving revision 1.42
> diff -u -p -r1.42 control.c
> --- control.c 21 Apr 2017 13:50:23 - 1.42
> +++ control.c 10 Jun 2018 16:59:01 -
> @@ -537,7 +537,7 @@ control_dispatch_agentx(int fd, short ev
> struct agentx_varbind_hdrvbhdr;
> struct ber_element **elm, **iter;
>
> - if (snmp_agentx_read_response(pdu, &resp) == -1) {
> + if (snmp_agentx_read_raw(pdu, &resp, sizeof(resp)) ==
> -1) {
> msg->sm_error = SNMP_ERROR_GENERR;
> goto dispatch;
> }
> Index: snmp.h
> ===
> RCS file: /cvs/src/usr.sbin/snmpd/snmp.h,v
> retrieving revision 1.14
> diff -u -p -r1.14 snmp.h
> --- snmp.h11 Jun 2015 18:49:09 - 1.14
> +++ snmp.h10 Jun 2018 16:59:01 -
> @@ -369,7 +369,6 @@ struct agentx_handle *
> struct agentx_handle *
> snmp_agentx_fdopen(int, char *, struct snmp_oid *);
> int snmp_agentx_response(struct agentx_handle *, struct agentx_pdu *);
> -int snmp_agentx_read_response(struct agentx_pdu *, struct
> agentx_response_data *);
> int snmp_agentx_open_response(struct agentx_handle *, struct agentx_pdu *);
> struct agentx_pdu *
> snmp_agentx_open_pdu(struct agentx_handle *, char *descr,
>
Re: route: improve inet6_makenetandmask
Here's a new diff that removes the duplicate parsing bits as mentioned
before but leaves masking the address to mask_addr() instead of doing it
manually.
Furthermore, it also stops route(8) from assuming address strings
without explicit prefix length to be /64.
The old behaviour described in RFC 2374 from 1998 is obsolete as per
RFC 3587 which states
RFC 2374 was the definition of addresses for Format Prefix 001
(2000::/3) which is formally made historic by this document. Even
though currently only 2000::/3 is being delegated by the IANA,
implementations should not make any assumptions about 2000::/3 being
special. In the future, the IANA might be directed to delegate
currently unassigned portions of the IPv6 address space for the
purpose of Global Unicast as well.
This was brought to my attention by the (recent) misc@ thread
"Confusing IPv6 route(8) results"[0] in which benno@ mentioned an
important side effect when it comes to using `-prefixlen' before the
address string since order is relavant here and the following would
therefore blackhole a single /128 with after my patch applied:
# route add -inet6 -prefixlen 56 2001:db8:: ::1 -blackhole
Thus, I'll put a note into current.html in case this change should go in.
FWIW, both FreeBSD and NetBSD already use `prefixlen()' and do not mask
the address in `inet6_makenetandmask()'. NetBSD still assumes /64 as per
RFC 2374 while FreeBSD does the same already I'm aiming for.
Regress passes, no regressions found when manually adding/removing
routes.
Feedback? Objections? OK?
0: https://marc.info/?l=openbsd-misc&m=152712936731762
Index: route.c
===
RCS file: /cvs/src/sbin/route/route.c,v
retrieving revision 1.214
diff -u -p -r1.214 route.c
--- route.c 1 May 2018 18:14:10 - 1.214
+++ route.c 10 Jun 2018 22:35:43 -
@@ -786,50 +786,19 @@ inet_makenetandmask(u_int32_t net, struc
sin->sin_len = 1 + cp - (char *)sin;
}
-/*
- * XXX the function may need more improvement...
- */
int
inet6_makenetandmask(struct sockaddr_in6 *sin6, char *plen)
{
- struct in6_addr in6;
- const char *errstr;
- int i, len, q, r;
-
- if (NULL==plen) {
+ if (!plen) {
if (IN6_IS_ADDR_UNSPECIFIED(&sin6->sin6_addr) &&
- sin6->sin6_scope_id == 0) {
+ sin6->sin6_scope_id == 0)
plen = "0";
- } else if ((sin6->sin6_addr.s6_addr[0] & 0xe0) == 0x20) {
- /* aggregatable global unicast - RFC2374 */
- memset(&in6, 0, sizeof(in6));
- if (!memcmp(&sin6->sin6_addr.s6_addr[8],
- &in6.s6_addr[8], 8))
- plen = "64";
- }
}
- if (!plen || strcmp(plen, "128") == 0)
+ if (!plen || prefixlen(AF_INET6, plen))
return (1);
- else {
- rtm_addrs |= RTA_NETMASK;
- prefixlen(AF_INET6, plen);
-
- len = strtonum(plen, 0, 128, &errstr);
- if (errstr)
- errx(1, "prefixlen %s is %s", plen, errstr);
-
- q = (128-len) >> 3;
- r = (128-len) & 7;
- i = 15;
- while (q-- > 0)
- sin6->sin6_addr.s6_addr[i--] = 0;
- if (r > 0)
- sin6->sin6_addr.s6_addr[i] &= 0xff << r;
-
- return (0);
- }
+ return (0);
}
/*
===
Stats: --- 35 lines 798 chars
Stats: +++ 4 lines 100 chars
Stats: -31 lines
Stats: -698 chars
Re: Odd Public WiFi breaks dhclient(8) but works for iPhone (Fix!)
I just checked how openbsd dhcpd handles this:
subnet 10.10.10.0 netmask 255.255.255.0 {
option routers 20.10.10.1;
range 10.10.10.10 10.10.10.50;
}
It starts fine and happily sends unusable configuration to client.
dhcpcd (dhcp client I use on linux-based client) installed funny routes:
0.0.0.0 -- 20.10.10.1
20.10.10.1 -- 0.0.0.0
So, Internet connection does not work.
I can't tell openbsd team what to do, but here are my thoughts:
If we believe that router should always be in client network then we should
fix dhcpd also making it to refuse to run with this configuration, should
not we?
If dhcpd accepts this config that means openbsd treats it as valid.
Then, we should not fix client also.
In theory one may need to send router address to client to be accessed
by different interface configured by different dhcp server (or, even,
manually).
But as far as I understand RFC, this is not allowed.
--
Sent from:
http://openbsd-archive.7691.n7.nabble.com/openbsd-dev-tech-f151936.html
