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