Re: Modify disklabel(8) manual about possible units
On Wed, Dec 07, 2016 at 05:39:22PM +0100, J?r?me FRGACIC wrote: > Hello tech, > > While reading disklabel(8) man page I remark that the two possibles > units '%' (percent of total) and '&' (percent of free) are only > mentioned in the description of the 'p' option but not in the section > which list available units. > > I would suggest to move the '%' and '&' units description in the later > section. > fixed, thanks (slightly different version committed). jmc > Index: disklabel.8 > === > RCS file: /cvs/src/sbin/disklabel/disklabel.8,v > retrieving revision 1.120 > diff -u -r1.120 disklabel.8 > --- disklabel.8 3 Dec 2016 07:34:39 - 1.120 > +++ disklabel.8 7 Dec 2016 16:32:06 - > @@ -157,11 +157,6 @@ > instead of sectors. > Valid units are b(ytes), c(ylinders), k(ilobytes), m(egabytes), g > (igabytes) and t(erabytes). > -For operations other than displaying a partition the > -.Ql % > -(percent of total) and > -.Ql & > -(percent of free) units are also accepted. > .It Fl R > Restore a disk label that was formatted in a prior operation and > saved in an > @@ -265,9 +260,13 @@ > for megabytes, > .Sq g > for gigabytes, > -and > .Sq t > -for terabytes. > +for terabytes, > +.Ql % > +for a percent of total > +and > +.Ql & > +for a percent of free. > If no unit is given, the default is to use sectors > (usually 512 bytes). > Quantities will be rounded to the nearest > > PS : I haven't subcribe to the tech mailing list, so please add me as > recipient if you reply. > > Kind regards, > > > J?r?me FRGACIC >
dhcrelay(8): filter BOOTREPLY packets
This diff makes dhcrelay(8) drop packets that were not meant for us.
This is a safety check suggested by jca@ to avoid relaying packets with
the address of other relays.
ok?
Index: dhcrelay.c
===
RCS file: /cvs/src/usr.sbin/dhcrelay/dhcrelay.c,v
retrieving revision 1.49
diff -u -p -r1.49 dhcrelay.c
--- dhcrelay.c 8 Dec 2016 19:18:15 - 1.49
+++ dhcrelay.c 8 Dec 2016 19:52:51 -
@@ -276,6 +276,11 @@ relay(struct interface_info *ip, struct
/* If it's a bootreply, forward it to the client. */
if (packet->op == BOOTREPLY) {
+ /* Filter packet that were not meant for us. */
+ if (packet->giaddr.s_addr !=
+ interfaces->primary_address.s_addr)
+ return;
+
bzero(&to, sizeof(to));
if (!(packet->flags & htons(BOOTP_BROADCAST))) {
to.sin_addr = packet->yiaddr;
Re: [ftp] missing new line in debug+verbose mode
That will add an extra newline in the proxy case where it does:
fprintf(ttyout, "Requesting %s", origline);
...
fprintf(ttyout, " (via %s)\n", proxyurl);
There is actually a newline printed for the non-proxy case but it
happens too late.
We either need to avoid printing a newline in the "Requesting"
message for the proxyurl case or just avoid splitting the message
in the first place, which is what I've done below.
- todd
Index: usr.bin/ftp/fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.150
diff -u -p -u -r1.150 fetch.c
--- usr.bin/ftp/fetch.c 8 Dec 2016 19:31:17 - 1.150
+++ usr.bin/ftp/fetch.c 8 Dec 2016 19:43:25 -
@@ -624,9 +624,6 @@ noslash:
fin = fdopen(s, "r+");
#endif /* !SMALL */
- if (verbose)
- fprintf(ttyout, "Requesting %s", origline);
-
/*
* Construct and send the request. Proxy requests don't want leading /.
*/
@@ -636,8 +633,10 @@ noslash:
epath = url_encode(path);
if (proxyurl) {
- if (verbose)
- fprintf(ttyout, " (via %s)\n", proxyurl);
+ if (verbose) {
+ fprintf(ttyout, "Requesting %s (via %s)\n",
+ origline, proxyurl);
+ }
/*
* Host: directive must use the destination host address for
* the original URI (path).
@@ -653,6 +652,8 @@ noslash:
"Host: %s\r\n%s%s\r\n\r\n",
epath, proxyhost, buf ? buf : "", httpuseragent);
} else {
+ if (verbose)
+ fprintf(ttyout, "Requesting %s\n", origline);
#ifndef SMALL
if (resume) {
struct stat stbuf;
@@ -712,8 +713,6 @@ noslash:
#endif /* !SMALL */
ftp_printf(fin, tls, "\r\n%s%s\r\n\r\n",
buf ? buf : "", httpuseragent);
- if (verbose)
- fprintf(ttyout, "\n");
}
free(epath);
dhcrelay(8): add support for layer 2 relaying
This diff implements layer 2 relaying support for dhcrelay with further
support for Relay Agent Info (RFC 3046). This feature is mostly used by
switched networks that might not be using IP addresses when in the edge
with the customer.
Basically this diff allows you to run dhcrelay on interfaces without
addresses and doesn't require you to specify an DHCP server address.
Instead you just need to specify the output port.
I also updated the man page to show the new options for layer 2 relaying
Relay Agent Info knobs, since you might want to let the remote DHCP
server know where the DHCP packet is coming from.
ok?
Index: bpf.c
===
RCS file: /cvs/src/usr.sbin/dhcrelay/bpf.c,v
retrieving revision 1.13
diff -u -p -r1.13 bpf.c
--- bpf.c 8 Dec 2016 19:18:15 - 1.13
+++ bpf.c 8 Dec 2016 19:34:44 -
@@ -93,6 +93,38 @@ if_register_send(struct interface_info *
}
/*
+ * Packet filter program: 'ip and udp and dst port CLIENT_PORT'
+ */
+struct bpf_insn dhcp_bpf_sfilter[] = {
+ /* Make sure this is an IP packet... */
+ BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 12),
+ BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, ETHERTYPE_IP, 0, 8),
+
+ /* Make sure it's a UDP packet... */
+ BPF_STMT(BPF_LD + BPF_B + BPF_ABS, 23),
+ BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 0, 6),
+
+ /* Make sure this isn't a fragment... */
+ BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 20),
+ BPF_JUMP(BPF_JMP + BPF_JSET + BPF_K, 0x1fff, 4, 0),
+
+ /* Get the IP header length... */
+ BPF_STMT(BPF_LDX + BPF_B + BPF_MSH, 14),
+
+ /* Make sure it's to the right port... */
+ BPF_STMT(BPF_LD + BPF_H + BPF_IND, 16),
+ BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, CLIENT_PORT, 0, 1),
+
+ /* If we passed all the tests, ask for the whole packet. */
+ BPF_STMT(BPF_RET+BPF_K, (u_int)-1),
+
+ /* Otherwise, drop it. */
+ BPF_STMT(BPF_RET+BPF_K, 0),
+};
+
+int dhcp_bpf_sfilter_len = sizeof(dhcp_bpf_sfilter) / sizeof(struct bpf_insn);
+
+/*
* Packet filter program: 'ip and udp and dst port SERVER_PORT'
*/
struct bpf_insn dhcp_bpf_filter[] = {
@@ -161,6 +193,38 @@ struct bpf_insn dhcp_bpf_efilter[] = {
int dhcp_bpf_efilter_len = sizeof(dhcp_bpf_efilter) / sizeof(struct bpf_insn);
/*
+ * Packet write filter program: 'ip and udp and src port CLIENT_PORT'
+ */
+struct bpf_insn dhcp_bpf_swfilter[] = {
+ /* Make sure this is an IP packet... */
+ BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 12),
+ BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, ETHERTYPE_IP, 0, 8),
+
+ /* Make sure it's a UDP packet... */
+ BPF_STMT(BPF_LD + BPF_B + BPF_ABS, 23),
+ BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 0, 6),
+
+ /* Make sure this isn't a fragment... */
+ BPF_STMT(BPF_LD + BPF_H + BPF_ABS, 20),
+ BPF_JUMP(BPF_JMP + BPF_JSET + BPF_K, 0x1fff, 4, 0),
+
+ /* Get the IP header length... */
+ BPF_STMT(BPF_LDX + BPF_B + BPF_MSH, 14),
+
+ /* Make sure it's from the right port... */
+ BPF_STMT(BPF_LD + BPF_H + BPF_IND, 14),
+ BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, CLIENT_PORT, 0, 1),
+
+ /* If we passed all the tests, ask for the whole packet. */
+ BPF_STMT(BPF_RET+BPF_K, (u_int)-1),
+
+ /* Otherwise, drop it. */
+ BPF_STMT(BPF_RET+BPF_K, 0),
+};
+
+int dhcp_bpf_swfilter_len = sizeof(dhcp_bpf_swfilter) / sizeof(struct
bpf_insn);
+
+/*
* Packet write filter program: 'ip and udp and src port SERVER_PORT'
*/
struct bpf_insn dhcp_bpf_wfilter[] = {
@@ -193,7 +257,7 @@ struct bpf_insn dhcp_bpf_wfilter[] = {
int dhcp_bpf_wfilter_len = sizeof(dhcp_bpf_wfilter) / sizeof(struct bpf_insn);
void
-if_register_receive(struct interface_info *info)
+if_register_receive(struct interface_info *info, int isserver)
{
struct bpf_version v;
struct bpf_program p;
@@ -234,7 +298,10 @@ if_register_receive(struct interface_inf
info->rbuf_len = 0;
/* Set up the bpf filter program structure. */
- if (info->hw_address.htype == HTYPE_IPSEC_TUNNEL) {
+ if (isserver) {
+ p.bf_len = dhcp_bpf_sfilter_len;
+ p.bf_insns = dhcp_bpf_sfilter;
+ } else if (info->hw_address.htype == HTYPE_IPSEC_TUNNEL) {
p.bf_len = dhcp_bpf_efilter_len;
p.bf_insns = dhcp_bpf_efilter;
} else {
@@ -245,8 +312,13 @@ if_register_receive(struct interface_inf
error("Can't install packet filter program: %m");
/* Set up the bpf write filter program structure. */
- p.bf_len = dhcp_bpf_wfilter_len;
- p.bf_insns = dhcp_bpf_wfilter;
+ if (isserver) {
+ p.bf_len = dhcp_bpf_swfilter_len;
+ p.bf_insns = dhcp_bpf_swfilter;
+ } else {
+ p.bf_len = dhcp_bpf_wfilter_len;
+ p.bf_insns = dhcp_bpf_wfilter;
+ }
if (ioctl(info->rfdesc, BIOCSETWF, &p) == -1)
ftp: avoid printf of NULL in debug mode
I noticed that Jiri's ftp debug output had two instances where NULL was printed as a string. This fixes it. $ ftp -o /dev/null -M -d -V http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/ Before: host ftp.eu.openbsd.org, port (null), path pub/OpenBSD/snapshots/amd64/, save as /dev/null, auth (null). After: host ftp.eu.openbsd.org, port http, path pub/OpenBSD/snapshots/amd64/, save as /dev/null, auth none. - todd Index: usr.bin/ftp/fetch.c === RCS file: /cvs/src/usr.bin/ftp/fetch.c,v retrieving revision 1.149 diff -u -p -u -r1.149 fetch.c --- usr.bin/ftp/fetch.c 20 Aug 2016 20:18:42 - 1.149 +++ usr.bin/ftp/fetch.c 8 Dec 2016 19:23:10 - @@ -470,6 +470,11 @@ noslash: portnum = strrchr(hosttail, ':'); /* find portnum */ if (portnum != NULL) *portnum++ = '\0'; +#ifndef SMALL + port = portnum ? portnum : (ishttpsurl ? httpsport : httpport); +#else /* !SMALL */ + port = portnum ? portnum : httpport; +#endif /* !SMALL */ #ifndef SMALL if (full_host == NULL) @@ -477,18 +482,13 @@ noslash: errx(1, "Cannot allocate memory for hostname"); if (debug) fprintf(ttyout, "host %s, port %s, path %s, " - "save as %s, auth %s.\n", - host, portnum, path, savefile, credentials); + "save as %s, auth %s.\n", host, port, path, + savefile, credentials ? credentials : "none"); #endif /* !SMALL */ memset(&hints, 0, sizeof(hints)); hints.ai_family = family; hints.ai_socktype = SOCK_STREAM; -#ifndef SMALL - port = portnum ? portnum : (ishttpsurl ? httpsport : httpport); -#else /* !SMALL */ - port = portnum ? portnum : httpport; -#endif /* !SMALL */ error = getaddrinfo(host, port, &hints, &res0); /* * If the services file is corrupt/missing, fall back
Re: dhcrelay(8): clean up function prototypes
Rafael Zalamena writes: > On Thu, Dec 08, 2016 at 06:59:18PM +0100, Jeremie Courreges-Anglas wrote: >> Rafael Zalamena writes: >> >> [...] >> >> >> Another problem: the relay->server code uses send(2) on a connected >> >> socket and thus has no destination IP issue. But the relay->client path >> >> now uses the source address from the server->relay packet. I think >> >> we should keep using interfaces->primary_address here... >> >> [...] >> >> > Here is the new diff with the improvements, ok? >> >> Thanks. Your diff still makes use of the server's source address to >> relay the BOOTREPLY to the client. I'd say that this is an important >> change and I'm not sure at all whether it is desirable. It surely can't >> be committed as part of a cleanup diff. > > Sorry, I forgot about that one. I got a multi relayed setup and it does > make a difference. > > Here is a new diff with your suggestion. Works fine here. > ok? ok jca@ BTW you can now kill struct iaddr. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: dhcrelay(8): clean up function prototypes
On Thu, Dec 08, 2016 at 06:59:18PM +0100, Jeremie Courreges-Anglas wrote:
> Rafael Zalamena writes:
>
> [...]
>
> >> Another problem: the relay->server code uses send(2) on a connected
> >> socket and thus has no destination IP issue. But the relay->client path
> >> now uses the source address from the server->relay packet. I think
> >> we should keep using interfaces->primary_address here...
>
> [...]
>
> > Here is the new diff with the improvements, ok?
>
> Thanks. Your diff still makes use of the server's source address to
> relay the BOOTREPLY to the client. I'd say that this is an important
> change and I'm not sure at all whether it is desirable. It surely can't
> be committed as part of a cleanup diff.
Sorry, I forgot about that one. I got a multi relayed setup and it does
make a difference.
Here is a new diff with your suggestion.
ok?
Index: bpf.c
===
RCS file: /home/obsdcvs/src/usr.sbin/dhcrelay/bpf.c,v
retrieving revision 1.12
diff -u -p -r1.12 bpf.c
--- bpf.c 8 Dec 2016 09:29:50 - 1.12
+++ bpf.c 8 Dec 2016 18:41:43 -
@@ -258,24 +258,23 @@ if_register_receive(struct interface_inf
ssize_t
send_packet(struct interface_info *interface,
-struct dhcp_packet *raw, size_t len, struct in_addr from,
-struct sockaddr_in *to, struct hardware *hto)
+struct dhcp_packet *raw, size_t len, struct packet_ctx *pc)
{
unsigned char buf[256];
struct iovec iov[2];
int result, bufp = 0;
if (interface->hw_address.htype == HTYPE_IPSEC_TUNNEL) {
- socklen_t slen = sizeof(*to);
+ socklen_t slen = pc->pc_dst.ss_len;
result = sendto(server_fd, raw, len, 0,
- (struct sockaddr *)to, slen);
+ (struct sockaddr *)&pc->pc_dst, slen);
goto done;
}
/* Assemble the headers... */
- assemble_hw_header(interface, buf, &bufp, hto);
- assemble_udp_ip_header(interface, buf, &bufp, from.s_addr,
- to->sin_addr.s_addr, to->sin_port, (unsigned char *)raw, len);
+ assemble_hw_header(interface, buf, &bufp, pc);
+ assemble_udp_ip_header(interface, buf, &bufp, pc,
+ (unsigned char *)raw, len);
/* Fire it off */
iov[0].iov_base = (char *)buf;
@@ -292,7 +291,7 @@ send_packet(struct interface_info *inter
ssize_t
receive_packet(struct interface_info *interface, unsigned char *buf,
-size_t len, struct sockaddr_in *from, struct hardware *hfrom)
+size_t len, struct packet_ctx *pc)
{
int length = 0, offset = 0;
struct bpf_hdr hdr;
@@ -358,7 +357,7 @@ receive_packet(struct interface_info *in
/* Decode the physical header... */
offset = decode_hw_header(interface,
- interface->rbuf, interface->rbuf_offset, hfrom);
+ interface->rbuf, interface->rbuf_offset, pc);
/*
* If a physical layer checksum failed (dunno of any
@@ -374,7 +373,7 @@ receive_packet(struct interface_info *in
/* Decode the IP and UDP headers... */
offset = decode_udp_ip_header(interface, interface->rbuf,
- interface->rbuf_offset, from, hdr.bh_caplen);
+ interface->rbuf_offset, pc, hdr.bh_caplen);
/* If the IP or UDP checksum was bad, skip the packet... */
if (offset < 0) {
Index: dhcpd.h
===
RCS file: /home/obsdcvs/src/usr.sbin/dhcrelay/dhcpd.h,v
retrieving revision 1.16
diff -u -p -r1.16 dhcpd.h
--- dhcpd.h 8 Dec 2016 09:29:50 - 1.16
+++ dhcpd.h 8 Dec 2016 18:41:43 -
@@ -42,15 +42,28 @@
#defineSERVER_PORT 67
#defineCLIENT_PORT 68
+/* Maximum size of client hardware address. */
+#define CHADDR_SIZE16
+
+struct packet_ctx {
+ uint8_t pc_htype;
+ uint8_t pc_hlen;
+ uint8_t pc_smac[CHADDR_SIZE];
+ uint8_t pc_dmac[CHADDR_SIZE];
+
+ struct sockaddr_storage pc_src;
+ struct sockaddr_storage pc_dst;
+};
+
struct iaddr {
int len;
- unsigned char iabuf[16];
+ unsigned char iabuf[CHADDR_SIZE];
};
struct hardware {
u_int8_t htype;
u_int8_t hlen;
- u_int8_t haddr[16];
+ u_int8_t haddr[CHADDR_SIZE];
};
/* Possible states in which the client can be. */
@@ -112,15 +125,13 @@ int if_register_bpf(struct interface_inf
void if_register_send(struct interface_info *);
void if_register_receive(struct interface_info *);
ssize_t send_packet(struct interface_info *,
-struct dhcp_packet *, size_t, struct in_addr,
-struct sockaddr_in *, struct hardware *);
+struct dhcp_packet *, size_t, struct packet_ctx *);
ssize_t rece
[ftp] missing new line in debug+verbose mode
See 'GET /url...' location in the output in the first example:
j.
$ ftp -o /dev/null -M -d http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/
host ftp.eu.openbsd.org, port (null), path pub/OpenBSD/snapshots/amd64/, save
as /dev/null, auth (null).
Trying 77.238.36.16...
Requesting http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/GET
/pub/OpenBSD/snapshots/amd64/ HTTP/1.0
Host: ftp.eu.openbsd.org
User-Agent: OpenBSD ftp
received 'HTTP/1.1 200 OK'
received 'Date: Thu, 08 Dec 2016 18:06:35 GMT'
received 'Server: Apache/2.2.22 (Ubuntu)'
received 'Vary: Accept-Encoding'
received 'Content-Length: 6018'
received 'Connection: close'
received 'Content-Type: text/html;charset=UTF-8'
6018 bytes received in 0.01 seconds (670.27 KB/s)
$ ftp -o /dev/null -M -d -V
http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/
host ftp.eu.openbsd.org, port (null), path pub/OpenBSD/snapshots/amd64/, save
as /dev/null, auth (null).
GET /pub/OpenBSD/snapshots/amd64/ HTTP/1.0
Host: ftp.eu.openbsd.org
User-Agent: OpenBSD ftp
received 'HTTP/1.1 200 OK'
received 'Date: Thu, 08 Dec 2016 18:06:44 GMT'
received 'Server: Apache/2.2.22 (Ubuntu)'
received 'Vary: Accept-Encoding'
received 'Content-Length: 6018'
received 'Connection: close'
received 'Content-Type: text/html;charset=UTF-8'
Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.149
diff -u -p -u -p -r1.149 fetch.c
--- fetch.c 20 Aug 2016 20:18:42 - 1.149
+++ fetch.c 8 Dec 2016 18:16:44 -
@@ -625,7 +625,7 @@ noslash:
#endif /* !SMALL */
if (verbose)
- fprintf(ttyout, "Requesting %s", origline);
+ fprintf(ttyout, "Requesting %s\n", origline);
/*
* Construct and send the request. Proxy requests don't want leading /.
$ /home/jirib/cvs/openbsd-src/usr.bin/ftp/obj/ftp -o /dev/null -M -d
http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/
host ftp.eu.openbsd.org, port (null), path pub/OpenBSD/snapshots/amd64/, save
as /dev/null, auth (null).
Trying 77.238.36.56...
Requesting http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/
GET /pub/OpenBSD/snapshots/amd64/ HTTP/1.0
Host: ftp.eu.openbsd.org
User-Agent: OpenBSD ftp
received 'HTTP/1.1 200 OK'
received 'Date: Thu, 08 Dec 2016 18:10:51 GMT'
received 'Server: Apache/2.2.22 (Ubuntu)'
received 'Vary: Accept-Encoding'
received 'Content-Length: 6018'
received 'Connection: close'
received 'Content-Type: text/html;charset=UTF-8'
6018 bytes received in 0.00 seconds (49.48 MB/s)
And comparison with curl:
$ curl -i -v -o /dev/null -s
http://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/amd64/
* Trying 77.238.36.56...
* TCP_NODELAY set
* Connected to ftp.eu.openbsd.org (77.238.36.56) port 80 (#0)
> GET /pub/OpenBSD/snapshots/amd64/ HTTP/1.1
> Host: ftp.eu.openbsd.org
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Thu, 08 Dec 2016 18:25:18 GMT
< Server: Apache/2.2.22 (Ubuntu)
< Vary: Accept-Encoding
< Content-Length: 6018
< Content-Type: text/html;charset=UTF-8
<
{ [2724 bytes data]
* Curl_http_done: called premature == 0
* Connection #0 to host ftp.eu.openbsd.org left intact
Re: dhcrelay(8): clean up function prototypes
Rafael Zalamena writes: [...] >> Another problem: the relay->server code uses send(2) on a connected >> socket and thus has no destination IP issue. But the relay->client path >> now uses the source address from the server->relay packet. I think >> we should keep using interfaces->primary_address here... [...] > Here is the new diff with the improvements, ok? Thanks. Your diff still makes use of the server's source address to relay the BOOTREPLY to the client. I'd say that this is an important change and I'm not sure at all whether it is desirable. It surely can't be committed as part of a cleanup diff. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: dhcrelay(8): clean up function prototypes
On Thu, Dec 08, 2016 at 05:07:41PM +0100, Jeremie Courreges-Anglas wrote:
> ---sniped---
> I think you've summoned Cthulhu with this diff. :)
>
> I started noticing a wrong behavior with when testing a multi-relay
> setup, as prompted by Patrick's diff. See
>
> marc.info/?l=openbsd-tech&m=148096893918967&w=2
>
> Such as setup didn't work before, and is still half-broken in -current.
>
> For the record:
>
> --8<--
> Addresses start with 192.168...
>
> [server] <-> [relay1] <-> [relay2] <-> [client]
> 1.1 1.22.1 2.23.1
>
> Here dhcrelay on relay2 ignores replies sent by 192.168.1.1 to
> 192.168.3.1, because its UDP socket is bound to 192.168.3.1 but
> connected to 192.168.2.2.
> -->8--
>
> A second problem is that, if [relay1] is on the path between [server] and
> [relay2], the BPF socket will catch [server]'s reply, think it has to
> handle it (I don't think it should), and send it to [client]. The code
> in dhcrelay(8) doesn't make enough checks to cope with such a situation.
> This is not a big problem in practice, but now your diff comes in.
>
> In got_response(), you store client_port, 68, in
> ss2sin(&pc->pc_dst)->sin_port. But in got_one() -> receive_packet() ->
> decode_udp_ip_header(), you store the UDP port of the incoming packet.
> In case of a [server]->[relay2] messages, the port is 67. [relay1] thus
> sends a packet to the client with 67 as the destination port. This
> packet matches the BPF filter of [relay1], which then goes in an
> infinite loop.
>
> IIUC, an obvious improvement would be to ignore BOOTREPLY packets with
> a giaddr that doesn't match our primary address. relay() could use such
> a check:
>
> /* If it's a bootreply, forward it to the client. */
> if (packet->op == BOOTREPLY) {
>
> /* Is this packet actually for us? */
> if (packet->giaddr.s_addr != interfaces->primary_address.s_addr)
> return;
> [...]
> }
>
> Maybe there is a drawback that I can't see, but blindly relaying like we
> do now can't be a good thing.
This is not the purpose of this diff, but we can fix it later in the next
diffs. I want to keep the scope on reducing the functions prototype and
less in fixing previous problems.
>
> The reason why port 67 ends up on the wire instead of port 68 is
> probably this:
>
> bzero(&to, sizeof(to));
> if (!(packet->flags & htons(BOOTP_BROADCAST))) {
> to.sin_addr = packet->yiaddr;
> to.sin_port = client_port;
> } else {
> to.sin_addr.s_addr = htonl(INADDR_BROADCAST);
> to.sin_port = client_port;
> }
> to.sin_family = AF_INET;
> to.sin_len = sizeof to;
> memcpy(&ss2sin(&pc->pc_dst)->sin_addr, &to.sin_addr,
> sizeof(ss2sin(&pc->pc_dst)->sin_addr));
>
> The memcpy copies only the IP address, not the port. This should
> be something like
>
> *ss2sin(&pc->pc_dst) = to;
New diff has this fix, thank you!
>
> Another problem: the relay->server code uses send(2) on a connected
> socket and thus has no destination IP issue. But the relay->client path
> now uses the source address from the server->relay packet. I think
> we should keep using interfaces->primary_address here...
>
> No idea if the proposals above would fix all the problems, but I have to
> finish this mail. :)
>
> Aside from this:
> - please drop the extra netinet/if_ether.h includes
> - not a problem per se, but such a simple function like ss2sin could
> probably be defined static inline in a header
I accept your suggestions and I have applied them.
Here is the new diff with the improvements, ok?
Index: bpf.c
===
RCS file: /home/obsdcvs/src/usr.sbin/dhcrelay/bpf.c,v
retrieving revision 1.12
diff -u -p -r1.12 bpf.c
--- bpf.c 8 Dec 2016 09:29:50 - 1.12
+++ bpf.c 8 Dec 2016 17:03:21 -
@@ -258,24 +258,23 @@ if_register_receive(struct interface_inf
ssize_t
send_packet(struct interface_info *interface,
-struct dhcp_packet *raw, size_t len, struct in_addr from,
-struct sockaddr_in *to, struct hardware *hto)
+struct dhcp_packet *raw, size_t len, struct packet_ctx *pc)
{
unsigned char buf[256];
struct iovec iov[2];
int result, bufp = 0;
if (interface->hw_address.htype == HTYPE_IPSEC_TUNNEL) {
- socklen_t slen = sizeof(*to);
+ socklen_t slen = pc->pc_dst.ss_len;
result = sendto(server_fd, raw, len, 0,
- (struct sockaddr *)to, slen);
+ (struct sockaddr *)&pc->pc_dst, slen);
goto done;
}
/* Assemble the headers... */
- assemble_hw_header(interface, buf, &bufp, hto);
- assemble_udp_ip_header(interface, buf, &bufp, from.s_
Re: make iwm show MCS rates in tcpdump
On Thu, Nov 17, 2016 at 02:58:21PM +0100, Stefan Sperling wrote:
> This change allows iwm(4) users to see which rates they're sending and
> receiving packets at (kinda useful for debugging rate scaling issues).
This is a follow-up fix to the diff quoted below (since committed).
Don't strip bits which indicate the "Number of Spatial Streams" (antennas).
These are part of the MCS index value.
Without this fix, MCS 8 and above are wrapped and displayed as MCS 0-7.
ok?
Index: if_iwm.c
===
RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
retrieving revision 1.150
diff -u -p -r1.150 if_iwm.c
--- if_iwm.c6 Dec 2016 12:57:20 - 1.150
+++ if_iwm.c8 Dec 2016 16:43:46 -
@@ -3321,7 +3321,8 @@ iwm_rx_rx_mpdu(struct iwm_softc *sc, str
if (phy_info->phy_flags &
htole16(IWM_RX_RES_PHY_FLAGS_OFDM_HT)) {
uint8_t mcs = (phy_info->rate_n_flags &
- htole32(IWM_RATE_HT_MCS_RATE_CODE_MSK));
+ htole32(IWM_RATE_HT_MCS_RATE_CODE_MSK |
+ IWM_RATE_HT_MCS_NSS_MSK));
tap->wr_rate = (0x80 | mcs);
} else {
uint8_t rate = (phy_info->rate_n_flags &
>
> To see rates in tcpdump you need to use -y and -v options.
> For example: tcpdump -i iwm0 -y IEEE802_11_RADIO -v type data
>
> Writing to a pcap file and then looking at data rates in wirehark works, too:
>
> tcpdump -i iwm0 -y IEEE802_11_RADIO -v -s 1500 -w /tmp/pcap
> wireshark /tmp/pcap
>
> Index: if_iwm.c
> ===
> RCS file: /cvs/src/sys/dev/pci/if_iwm.c,v
> retrieving revision 1.146
> diff -u -p -r1.146 if_iwm.c
> --- if_iwm.c 1 Nov 2016 13:49:50 - 1.146
> +++ if_iwm.c 17 Nov 2016 13:46:24 -
> @@ -3319,12 +3319,9 @@ iwm_rx_rx_mpdu(struct iwm_softc *sc, str
> tap->wr_tsft = phy_info->system_timestamp;
> if (phy_info->phy_flags &
> htole16(IWM_RX_RES_PHY_FLAGS_OFDM_HT)) {
> -#ifdef notyet
> uint8_t mcs = (phy_info->rate_n_flags &
> htole32(IWM_RATE_HT_MCS_RATE_CODE_MSK));
> -#endif
> - /* XXX need a way to pass current MCS in 11n mode */
> - tap->wr_rate = 0;
> + tap->wr_rate = (0x80 | mcs);
> } else {
> uint8_t rate = (phy_info->rate_n_flags &
> htole32(IWM_RATE_LEGACY_RATE_MSK));
> @@ -3940,9 +3937,11 @@ iwm_tx(struct iwm_softc *sc, struct mbuf
> tap->wt_flags = 0;
> tap->wt_chan_freq = htole16(ni->ni_chan->ic_freq);
> tap->wt_chan_flags = htole16(ni->ni_chan->ic_flags);
> - if (rinfo->plcp == IWM_RATE_INVM_PLCP) {
> - /* XXX need a way to pass current MCS in 11n mode */
> - tap->wt_rate = 0;
> + if ((ni->ni_flags & IEEE80211_NODE_HT) &&
> + !IEEE80211_IS_MULTICAST(wh->i_addr1) &&
> + type == IEEE80211_FC0_TYPE_DATA &&
> + rinfo->plcp == IWM_RATE_INVM_PLCP) {
> + tap->wt_rate = (0x80 | rinfo->ht_plcp);
> } else
> tap->wt_rate = rinfo->rate;
> tap->wt_hwqueue = ac;
>
Re: dhcrelay(8): clean up function prototypes
Rafael Zalamena writes:
> On Wed, Dec 07, 2016 at 09:36:24PM +0100, Jeremie Courreges-Anglas wrote:
>> Rafael Zalamena writes:
>>
>> > I'm implementing some features for dhcrelay and to make them fit I need
>> > some clean ups in the dhcrelay(8) first. This diff changes most of the
>> > input/output functions prototypes to take one parameter with all addresses
>> > instead of passing multiple parameters.
>> >
>> > Basically this will make input functions gather more information (source/
>> > destination MACs, source/destination IPs, source/destination ports) and
>> > use it in the output instead of trying to figure out this information along
>> > the way.
>> >
>> > With this we will be able to add IPv6 support and layer 2 relaying.
>>
>> Nice. :)
>>
>> [...]
>>
>> > ok?
>>
>> This conflicts with a diff that has been committed by patrick@, you'll
>> need to refresh it.
>
> I updated the diff with the latest commits from patrick@. Basically instead
> of cleaning hto to trigger the memset(, 0xff,) on destination mac we just
> update the pc dmac field (see assemble_hw_header()).
Thanks!
>>
>> I didn't review it entirely, but please address the point below.
>
> I changed the struct fields sss and dss to src and dst respectively.
>
> ok?
I think you've summoned Cthulhu with this diff. :)
I started noticing a wrong behavior with when testing a multi-relay
setup, as prompted by Patrick's diff. See
marc.info/?l=openbsd-tech&m=148096893918967&w=2
Such as setup didn't work before, and is still half-broken in -current.
For the record:
--8<--
Addresses start with 192.168...
[server] <-> [relay1] <-> [relay2] <-> [client]
1.1 1.22.1 2.23.1
Here dhcrelay on relay2 ignores replies sent by 192.168.1.1 to
192.168.3.1, because its UDP socket is bound to 192.168.3.1 but
connected to 192.168.2.2.
-->8--
A second problem is that, if [relay1] is on the path between [server] and
[relay2], the BPF socket will catch [server]'s reply, think it has to
handle it (I don't think it should), and send it to [client]. The code
in dhcrelay(8) doesn't make enough checks to cope with such a situation.
This is not a big problem in practice, but now your diff comes in.
In got_response(), you store client_port, 68, in
ss2sin(&pc->pc_dst)->sin_port. But in got_one() -> receive_packet() ->
decode_udp_ip_header(), you store the UDP port of the incoming packet.
In case of a [server]->[relay2] messages, the port is 67. [relay1] thus
sends a packet to the client with 67 as the destination port. This
packet matches the BPF filter of [relay1], which then goes in an
infinite loop.
IIUC, an obvious improvement would be to ignore BOOTREPLY packets with
a giaddr that doesn't match our primary address. relay() could use such
a check:
/* If it's a bootreply, forward it to the client. */
if (packet->op == BOOTREPLY) {
/* Is this packet actually for us? */
if (packet->giaddr.s_addr != interfaces->primary_address.s_addr)
return;
[...]
}
Maybe there is a drawback that I can't see, but blindly relaying like we
do now can't be a good thing.
The reason why port 67 ends up on the wire instead of port 68 is
probably this:
bzero(&to, sizeof(to));
if (!(packet->flags & htons(BOOTP_BROADCAST))) {
to.sin_addr = packet->yiaddr;
to.sin_port = client_port;
} else {
to.sin_addr.s_addr = htonl(INADDR_BROADCAST);
to.sin_port = client_port;
}
to.sin_family = AF_INET;
to.sin_len = sizeof to;
memcpy(&ss2sin(&pc->pc_dst)->sin_addr, &to.sin_addr,
sizeof(ss2sin(&pc->pc_dst)->sin_addr));
The memcpy copies only the IP address, not the port. This should
be something like
*ss2sin(&pc->pc_dst) = to;
Another problem: the relay->server code uses send(2) on a connected
socket and thus has no destination IP issue. But the relay->client path
now uses the source address from the server->relay packet. I think
we should keep using interfaces->primary_address here...
No idea if the proposals above would fix all the problems, but I have to
finish this mail. :)
Aside from this:
- please drop the extra netinet/if_ether.h includes
- not a problem per se, but such a simple function like ss2sin could
probably be defined static inline in a header
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
openbsd test results
Hi, We are doing some regression and performance testing with OpenBSD -currrent. The daily results are published on this web site. http://bluhm.genua.de/ bluhm
Re: add commented out spamd config to default syslog.conf
On Thu, Dec 08, 2016 at 01:16:43PM +, Stuart Henderson wrote:
> On 2016/12/08 09:42, Landry Breuil wrote:
> > Hi,
> >
> > i know this is in the examples section of syslog.conf(5), but i got
> > bitten by this again, so what do ppl thing about adding those 3 lines to
> > the default syslog.conf ?
> >
> > wont push for this, was just taunted by someone "i would OK a diff to
> > add an example to the default syslog.conf" :)
> >
> > Landry
> >
> > Index: etc/syslog.conf
> > ===
> > RCS file: /cvs/src/etc/syslog.conf,v
> > retrieving revision 1.19
> > diff -u -r1.19 syslog.conf
> > --- etc/syslog.conf 26 Nov 2015 15:25:14 - 1.19
> > +++ etc/syslog.conf 8 Dec 2016 08:39:21 -
> > @@ -1,6 +1,13 @@
> > # $OpenBSD: syslog.conf,v 1.19 2015/11/26 15:25:14 deraadt Exp $
> > #
> >
> > +# Uncomment these three lines to log messages from spamd(8) to its own
> > +# logfile, without being also logged in /var/log/daemon.
> > +# Note that the logfile has to be created beforehands.
> > +#!!spamd
> > +#daemon.info /var/log/spamd
> > +#!*
> > +
> > *.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none
> > /var/log/messages
> > kern.debug;syslog,user.info
> > /var/log/messages
> > auth.info /var/log/authlog
> >
>
> I'm not sure if we need to tell people to create the file; at least
> we don't tell them to create files for other commented-out examples
> (uucp, doas).
>
> Slight tweaks to the english, plus I tweaked the doas example to
> try and make the difference clear between it and the first example
> ("instead of" vs "as well as").
Much betterer than my initial brokenglish version :)
Xeon-D R2PCIe Agent pcidevs
Hi all, i have this supermicro box: https://www.supermicro.nl/products/motherboard/Xeon/D/X10SDV-TP8F.cfm dmesg without this patch shows : vendor "Intel", unknown product 0x6f34 (class DASP subclass Time and Frequency, rev 0x03) at pci12 dev 16 function 1 not configured with this patch: "Intel Xeon-D R2PCIe Agent" rev 0x03 at pci12 dev 16 function 1 not configured full dmesg with patch: OpenBSD 6.0-current (GENERIC.MP) #10: Thu Dec 8 14:16:29 CET 2016 r...@bsdtest.srce.hr:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17055727616 (16265MB) avail mem = 16534257664 (15768MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xed9b0 (47 entries) bios0: vendor American Megatrends Inc. version "1.0a" date 05/05/2016 bios0: Supermicro Super Server acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT SPMI MCFG UEFI DBG2 HPET WDDT SSDT SSDT SSDT PRAD DMAR HEST BERT ERST EINJ acpi0: wakeup devices IP2P(S4) XHCI(S4) EHC1(S4) EHC2(S4) RP07(S4) RP08(S4) BR1A(S4) BR1B(S4) BR2A(S4) BR2B(S4) BR2C(S4) BR2D(S4) BR3A(S4) BR3B(S4) BR3C(S4) BR3D(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.33 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU D-1518 @ 2.20GHz, 2200.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,PQM,RDSEED,ADX,SMAP,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0: apid 9 pa 0xfec01000, version 20, 24 pins acpimcfg0 at acpi0 addr 0x8000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 255 (UNC0) acpiprt1 at acpi0: bus 0 (PCI0) acpiprt2 at acpi0: bus 1 (BR1A) acpiprt3 at acpi0: bus 2 (BR1B) acpiprt4 at acpi0: bus 4 (BR2C) acpiprt5 at acpi0: bus 5 (BR3A) acpiprt6 at acpi0: bus 7 (RP01) acpiprt7 at acpi0: bus 8 (RP02) acpiprt8 at acpi0: bus 9 (RP04) acpiprt9 at acpi0: bus 10 (BR3B) acpiprt10 at acpi0: bus 11 (RP05) acpicpu0 at acpi0: C2(350@41 mwait.3@0x20), C1(1016@1 mwait.1), PSS acpicpu1 at acpi0: C2(350@41 mwait.3@0x20), C1(1016@1 mwait.1), PSS acpicpu2 at acpi0: C2(350@41 mwait.3@0x20), C1(1016@1 mwait.1), PSS acpicpu3 at acpi0: C2(350@41 mwait.3@0x20), C1(1016@1 mwait.1), PSS "ACPI0004" at acpi0 not configured "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured "ACPI0007" at acpi0 not configured "PNP0C33" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0003" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0501" at acpi0 not configured "PNP0501" at acpi0 not configured "IPI0001" at acpi0 not configured acpibtn0 at acpi0: PWRB ipmi
Re: add commented out spamd config to default syslog.conf
On 2016/12/08 09:42, Landry Breuil wrote:
> Hi,
>
> i know this is in the examples section of syslog.conf(5), but i got
> bitten by this again, so what do ppl thing about adding those 3 lines to
> the default syslog.conf ?
>
> wont push for this, was just taunted by someone "i would OK a diff to
> add an example to the default syslog.conf" :)
>
> Landry
>
> Index: etc/syslog.conf
> ===
> RCS file: /cvs/src/etc/syslog.conf,v
> retrieving revision 1.19
> diff -u -r1.19 syslog.conf
> --- etc/syslog.conf 26 Nov 2015 15:25:14 - 1.19
> +++ etc/syslog.conf 8 Dec 2016 08:39:21 -
> @@ -1,6 +1,13 @@
> #$OpenBSD: syslog.conf,v 1.19 2015/11/26 15:25:14 deraadt Exp $
> #
>
> +# Uncomment these three lines to log messages from spamd(8) to its own
> +# logfile, without being also logged in /var/log/daemon.
> +# Note that the logfile has to be created beforehands.
> +#!!spamd
> +#daemon.info /var/log/spamd
> +#!*
> +
> *.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none
> /var/log/messages
> kern.debug;syslog,user.info /var/log/messages
> auth.info/var/log/authlog
>
I'm not sure if we need to tell people to create the file; at least
we don't tell them to create files for other commented-out examples
(uucp, doas).
Slight tweaks to the english, plus I tweaked the doas example to
try and make the difference clear between it and the first example
("instead of" vs "as well as").
Index: syslog.conf
===
RCS file: /cvs/src/etc/syslog.conf,v
retrieving revision 1.19
diff -u -p -r1.19 syslog.conf
--- syslog.conf 26 Nov 2015 15:25:14 - 1.19
+++ syslog.conf 8 Dec 2016 13:13:35 -
@@ -1,6 +1,12 @@
# $OpenBSD: syslog.conf,v 1.19 2015/11/26 15:25:14 deraadt Exp $
#
+# Uncomment these three lines to log messages from spamd(8) to a
+# separate file instead of being logged in /var/log/daemon.
+#!!spamd
+#daemon.info /var/log/spamd
+#!*
+
*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none
/var/log/messages
kern.debug;syslog,user.info/var/log/messages
auth.info /var/log/authlog
@@ -31,8 +37,8 @@ mail.info
/var/log/maillog
#*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none @loghost
#auth,daemon,syslog,user.info;authpriv,kern.debug @loghost
-# Uncomment to log messages from doas(1) to its own log file. Matches are done
-# based on the program name.
+# Uncomment to log messages from doas(1) to its own log file as well
+# as the normal logs above. Matches are done based on the program name.
# Program-specific logs:
#!doas
#*.* /var/log/doas
Re: dhcrelay(8): clean up function prototypes
On Wed, Dec 07, 2016 at 09:36:24PM +0100, Jeremie Courreges-Anglas wrote:
> Rafael Zalamena writes:
>
> > I'm implementing some features for dhcrelay and to make them fit I need
> > some clean ups in the dhcrelay(8) first. This diff changes most of the
> > input/output functions prototypes to take one parameter with all addresses
> > instead of passing multiple parameters.
> >
> > Basically this will make input functions gather more information (source/
> > destination MACs, source/destination IPs, source/destination ports) and
> > use it in the output instead of trying to figure out this information along
> > the way.
> >
> > With this we will be able to add IPv6 support and layer 2 relaying.
>
> Nice. :)
>
> [...]
>
> > ok?
>
> This conflicts with a diff that has been committed by patrick@, you'll
> need to refresh it.
I updated the diff with the latest commits from patrick@. Basically instead
of cleaning hto to trigger the memset(, 0xff,) on destination mac we just
update the pc dmac field (see assemble_hw_header()).
>
> I didn't review it entirely, but please address the point below.
I changed the struct fields sss and dss to src and dst respectively.
ok?
Index: bpf.c
===
RCS file: /home/obsdcvs/src/usr.sbin/dhcrelay/bpf.c,v
retrieving revision 1.11
diff -u -p -r1.11 bpf.c
--- bpf.c 28 May 2016 07:00:18 - 1.11
+++ bpf.c 8 Dec 2016 09:10:23 -
@@ -258,24 +258,23 @@ if_register_receive(struct interface_inf
ssize_t
send_packet(struct interface_info *interface,
-struct dhcp_packet *raw, size_t len, struct in_addr from,
-struct sockaddr_in *to, struct hardware *hto)
+struct dhcp_packet *raw, size_t len, struct packet_ctx *pc)
{
unsigned char buf[256];
struct iovec iov[2];
int result, bufp = 0;
if (interface->hw_address.htype == HTYPE_IPSEC_TUNNEL) {
- socklen_t slen = sizeof(*to);
+ socklen_t slen = pc->pc_dst.ss_len;
result = sendto(server_fd, raw, len, 0,
- (struct sockaddr *)to, slen);
+ (struct sockaddr *)&pc->pc_dst, slen);
goto done;
}
/* Assemble the headers... */
- assemble_hw_header(interface, buf, &bufp, hto);
- assemble_udp_ip_header(interface, buf, &bufp, from.s_addr,
- to->sin_addr.s_addr, to->sin_port, (unsigned char *)raw, len);
+ assemble_hw_header(interface, buf, &bufp, pc);
+ assemble_udp_ip_header(interface, buf, &bufp, pc,
+ (unsigned char *)raw, len);
/* Fire it off */
iov[0].iov_base = (char *)buf;
@@ -292,7 +291,7 @@ send_packet(struct interface_info *inter
ssize_t
receive_packet(struct interface_info *interface, unsigned char *buf,
-size_t len, struct sockaddr_in *from, struct hardware *hfrom)
+size_t len, struct packet_ctx *pc)
{
int length = 0, offset = 0;
struct bpf_hdr hdr;
@@ -358,7 +357,7 @@ receive_packet(struct interface_info *in
/* Decode the physical header... */
offset = decode_hw_header(interface,
- interface->rbuf, interface->rbuf_offset, hfrom);
+ interface->rbuf, interface->rbuf_offset, pc);
/*
* If a physical layer checksum failed (dunno of any
@@ -374,7 +373,7 @@ receive_packet(struct interface_info *in
/* Decode the IP and UDP headers... */
offset = decode_udp_ip_header(interface, interface->rbuf,
- interface->rbuf_offset, from, hdr.bh_caplen);
+ interface->rbuf_offset, pc, hdr.bh_caplen);
/* If the IP or UDP checksum was bad, skip the packet... */
if (offset < 0) {
Index: dhcpd.h
===
RCS file: /home/obsdcvs/src/usr.sbin/dhcrelay/dhcpd.h,v
retrieving revision 1.15
diff -u -p -r1.15 dhcpd.h
--- dhcpd.h 7 Dec 2016 13:19:18 - 1.15
+++ dhcpd.h 8 Dec 2016 09:10:23 -
@@ -42,15 +42,28 @@
#defineSERVER_PORT 67
#defineCLIENT_PORT 68
+/* Maximum size of client hardware address. */
+#define CHADDR_SIZE16
+
+struct packet_ctx {
+ uint8_t pc_htype;
+ uint8_t pc_hlen;
+ uint8_t pc_smac[CHADDR_SIZE];
+ uint8_t pc_dmac[CHADDR_SIZE];
+
+ struct sockaddr_storage pc_src;
+ struct sockaddr_storage pc_dst;
+};
+
struct iaddr {
int len;
- unsigned char iabuf[16];
+ unsigned char iabuf[CHADDR_SIZE];
};
struct hardware {
u_int8_t htype;
u_int8_t hlen;
- u_int8_t haddr[16];
+ u_int8_t haddr[CHADDR_SIZE];
};
/* Possible states in which the client can be. */
@@ -112,15 +125,13 @@ int if_register_bpf(struct interface
add commented out spamd config to default syslog.conf
Hi, i know this is in the examples section of syslog.conf(5), but i got bitten by this again, so what do ppl thing about adding those 3 lines to the default syslog.conf ? wont push for this, was just taunted by someone "i would OK a diff to add an example to the default syslog.conf" :) Landry Index: etc/syslog.conf === RCS file: /cvs/src/etc/syslog.conf,v retrieving revision 1.19 diff -u -r1.19 syslog.conf --- etc/syslog.conf 26 Nov 2015 15:25:14 - 1.19 +++ etc/syslog.conf 8 Dec 2016 08:39:21 - @@ -1,6 +1,13 @@ # $OpenBSD: syslog.conf,v 1.19 2015/11/26 15:25:14 deraadt Exp $ # +# Uncomment these three lines to log messages from spamd(8) to its own +# logfile, without being also logged in /var/log/daemon. +# Note that the logfile has to be created beforehands. +#!!spamd +#daemon.info /var/log/spamd +#!* + *.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none /var/log/messages kern.debug;syslog,user.info/var/log/messages auth.info /var/log/authlog
