Re: dhcrelay
Hi,
You will find the answer in the second paragraph of the description for
the dhcrelay(8) manpage.
It's fantastic that we don't even need the internet to find the answer.
Happy reading.
Joe
On 30/08/2019 8:21 AM, shadrock uhuru wrote:
hiya
thanks for the reply
hi eveyone
if i have a dhcp server in subnet A connected to interface em0 (lan) and
subnet B connected to interface iwn0 (wireless zone) on the router
with dhcrelay -i em0 running on the router should the wireless subnet be
able?? to get its dhcp address from the dhcp server on the lan ?
No, you would need to run
dhcrelay -i iwn0
to do that.
finally got that sorted,
but led me to another question
i have two dhcp servers on samba domain controllers,
can a second server-ip address be added like this to dhcrelay
dhcrelay -i iwn0
i haven't seen any examples like this on the net
shadrock
Re: dhcrelay
hiya thanks for the reply > hi eveyone > if i have a dhcp server in subnet A connected to interface em0 (lan) and > subnet B connected to interface iwn0 (wireless zone) on the router > with dhcrelay -i em0 running on the router should the wireless subnet be > able?? to get its dhcp address from the dhcp server on the lan ? > No, you would need to run > >dhcrelay -i iwn0 > > to do that. finally got that sorted, but led me to another question i have two dhcp servers on samba domain controllers, can a second server-ip address be added like this to dhcrelay dhcrelay -i iwn0 i haven't seen any examples like this on the net shadrock
Re: Re :dhcrelay
shadrock uhuru(niyal...@gmail.com) on 2019.08.25 17:14:48 +0100: > > To: > > shadrock uhuru > > CC: > > misc@openbsd.org > > > > > > shadrock uhuru(niyal...@gmail.com) on 2019.08.23 18:46:32 +0100: > >> hi eveyone > >> if i have a dhcp server in subnet A connected to interface em0 (lan) and > >> subnet B connected to interface iwn0 (wireless zone) on the router > >> with dhcrelay -i em0 running on the router should the wireless subnet be > >> able?? to get its dhcp address from the dhcp server on the lan ? > > No, you would need to run > > > >dhcrelay -i iwn0 > > > > to do that. > > > > Subject: > > Re: dhcrelay > > From: > > Sebastian Benoit > > Date: > > 8/23/19, 10:12 PM > > > thank Sebastian > i have two samba?? active domain controllers with dhcp installed on each, > is it possible to do this > > dhcrelay -i iwn0 Yes. But why did you not just read the manpage and try it out?
Re :dhcrelay
> To: > shadrock uhuru > CC: > misc@openbsd.org > > > shadrock uhuru(niyal...@gmail.com) on 2019.08.23 18:46:32 +0100: >> hi eveyone >> if i have a dhcp server in subnet A connected to interface em0 (lan) and >> subnet B connected to interface iwn0 (wireless zone) on the router >> with dhcrelay -i em0 running on the router should the wireless subnet be >> able?? to get its dhcp address from the dhcp server on the lan ? > No, you would need to run > >dhcrelay -i iwn0 > > to do that. > > Subject: > Re: dhcrelay > From: > Sebastian Benoit > Date: > 8/23/19, 10:12 PM > thank Sebastian i have two samba active domain controllers with dhcp installed on each, is it possible to do this dhcrelay -i iwn0 or can only one dhcp server address be specified ? shadrock
Re: dhcrelay
shadrock uhuru(niyal...@gmail.com) on 2019.08.23 18:46:32 +0100: > hi eveyone > if i have a dhcp server in subnet A connected to interface em0 (lan) and > subnet B connected to interface iwn0 (wireless zone) on the router > with dhcrelay -i em0 running on the router should the wireless subnet be > able?? to get its dhcp address from the dhcp server on the lan ? No, you would need to run dhcrelay -i iwn0 to do that.
dhcrelay
hi eveyone if i have a dhcp server in subnet A connected to interface em0 (lan) and subnet B connected to interface iwn0 (wireless zone) on the router with dhcrelay -i em0 running on the router should the wireless subnet be able to get its dhcp address from the dhcp server on the lan ?
Re: dhcrelay multiple instances possible bug
Hi Riccardo,
dhrelay only operates on a single interface, so you're not missing anything
there.
Can you show me the ps output for the dhcrelay processes you start? The rcctl
commands you show below don't include the rcctl start dhcrelay and
dhcrelay_second bits.
I have the following in rc.local (mostly because this config predates rcctl):
foo=192.0.2.194
bar=192.0.2.196
echo -n 'start dhcp relays:'
for i in vlan371 vlan373 \
vlan835 \
vlan801 vlan847 vlan866 vlan867 \
vlan811 vlan815 vlan816 \
vlan1101 vlan1147 vlan1165 vlan1166 \
vlan1201 vlan1231 vlan1247 vlan1265 vlan1266 \
vlan1301 vlan1331 vlan1347 vlan1365 vlan1366 \
vlan971 vlan966 \
vlan1401 vlan1465 vlan1466 vlan1467 \
vlan1501 vlan1565 vlan1566 \
vlan1601 vlan1647 vlan1665 vlan1666 vlan1667 \
vlan1701 vlan1747 vlan1765 vlan1766 \
vlan1801 vlan1865 vlan1866 \
vlan1901 vlan1965 vlan1966 \
vlan2001 vlan2065 vlan2066 vlan2067 \
vlan2008 vlan2068 \
vlan2506 vlan2533 vlan2536 vlan2531 vlan2537 vlan2547; do
/usr/sbin/dhcrelay -i ${i} $foo $bar
echo -n " ${i}"
done
echo '.'
Which produces:
xdlg@shotgun1 pf$ ps -aux | grep dhc
_dhcp40965 0.0 0.0 532 1008 ?? Ssp 10Nov17 12:06.67
/usr/sbin/dhcrelay -i vlan371 192.0.2.194 192.0.2.196
_dhcp16825 0.0 0.0 536 1012 ?? Ssp 10Nov172:08.80
/usr/sbin/dhcrelay -i vlan867 192.0.2.194 192.0.2.196
_dhcp69672 0.0 0.0 532 1076 ?? Isp 10Nov170:46.06
/usr/sbin/dhcrelay -i vlan866 192.0.2.194 192.0.2.196
_dhcp48117 0.0 0.0 536 972 ?? Isp 10Nov170:00.02
/usr/sbin/dhcrelay -i vlan373 192.0.2.194 192.0.2.196
_dhcp43065 0.0 0.0 540 1068 ?? Isp 10Nov170:06.02
/usr/sbin/dhcrelay -i vlan835 192.0.2.194 192.0.2.196
_dhcp77793 0.0 0.0 540 988 ?? Ssp 10Nov17 19:26.92
/usr/sbin/dhcrelay -i vlan801 192.0.2.194 192.0.2.196
_dhcp68793 0.0 0.0 540 1028 ?? Isp 10Nov170:08.40
/usr/sbin/dhcrelay -i vlan847 192.0.2.194 192.0.2.196
_dhcp12879 0.0 0.0 540 1016 ?? Isp 10Nov171:14.46
/usr/sbin/dhcrelay -i vlan1101 192.0.2.194 192.0.2.196
_dhcp10430 0.0 0.0 544 1052 ?? Ssp 10Nov171:42.55
/usr/sbin/dhcrelay -i vlan811 192.0.2.194 192.0.2.196
_dhcp87753 0.0 0.0 544 1016 ?? Isp 10Nov170:31.65
/usr/sbin/dhcrelay -i vlan815 192.0.2.194 192.0.2.196
_dhcp21434 0.0 0.0 536 1024 ?? Isp 10Nov170:00.20
/usr/sbin/dhcrelay -i vlan816 192.0.2.194 192.0.2.196
_dhcp17816 0.0 0.0 540 1020 ?? Isp 10Nov170:00.00
/usr/sbin/dhcrelay -i vlan1147 192.0.2.194 192.0.2.196
_dhcp67338 0.0 0.0 540 1020 ?? Isp 10Nov170:00.11
/usr/sbin/dhcrelay -i vlan1247 192.0.2.194 192.0.2.196
_dhcp73549 0.0 0.0 540 1020 ?? Isp 10Nov170:00.55
/usr/sbin/dhcrelay -i vlan1165 192.0.2.194 192.0.2.196
_dhcp78748 0.0 0.0 540 1012 ?? Isp 10Nov170:02.33
/usr/sbin/dhcrelay -i vlan1166 192.0.2.194 192.0.2.196
_dhcp82689 0.0 0.0 540 1008 ?? Isp 10Nov172:02.18
/usr/sbin/dhcrelay -i vlan1201 192.0.2.194 192.0.2.196
_dhcp31199 0.0 0.0 540 996 ?? Isp 10Nov170:07.63
/usr/sbin/dhcrelay -i vlan1231 192.0.2.194 192.0.2.196
_dhcp21332 0.0 0.0 532 1004 ?? Isp 10Nov171:24.02
/usr/sbin/dhcrelay -i vlan1265 192.0.2.194 192.0.2.196
_dhcp35688 0.0 0.0 544 1040 ?? Isp 10Nov170:00.28
/usr/sbin/dhcrelay -i vlan1347 192.0.2.194 192.0.2.196
_dhcp36741 0.0 0.0 540 1032 ?? Isp 10Nov170:07.17
/usr/sbin/dhcrelay -i vlan1266 192.0.2.194 192.0.2.196
_dhcp90274 0.0 0.0 544 1024 ?? Isp 10Nov17 19:17.78
/usr/sbin/dhcrelay -i vlan1301 192.0.2.194 192.0.2.196
_dhcp42199 0.0 0.0 548 1052 ?? Isp 10Nov170:00.17
/usr/sbin/dhcrelay -i vlan1331 192.0.2.194 192.0.2.196
_dhcp83979 0.0 0.0 528 1000 ?? Ssp 10Nov172:09.78
/usr/sbin/dhcrelay -i vlan1365 192.0.2.194 192.0.2.196
_dhcp52142 0.0 0.0 536 792 ?? Isp 10Nov170:00.00
/usr/sbin/dhcrelay -i vlan965 192.0.2.194 192.0.2.196
_dhcp17747 0.0 0.0 540 996 ?? Isp 10Nov170:05.03
/usr/sbin/dhcrelay -i vlan1366 192.0.2.194 192.0.2.196
_dhcp85673 0.0 0.0 536 988 ?? Isp 10Nov170:11.59
/usr/sbin/dhcrelay -i vlan947 192.0.2.194 192.0.2.196
_dhcp 266 0.0 0.0 536 964 ?? Isp 10Nov170:01.84
/usr/sbin/dhcrelay -i vlan966 192.0.2.194 192.0.2.196
_dhcp59857 0.0 0.0 540 984 ?? Isp 10Nov174:26.67
/usr/sbin/dhcrelay -i vlan1401 192.0.2.194 192.0.2.196
_dhcp17159 0.0 0.0 536 1012 ?? Ssp 10Nov171:27.85
/usr/sbin/dhcrelay -i vlan971 192.0.2.194 192.0.2.196
_dhcp67613 0.0 0.0 540 1028 ?? Isp 10Nov172:29.27
/usr/sbin/dhcrelay -i vlan1465 192.0.2.194 192.0.2.196
_dhcp33040 0.0 0.0 536 840 ?? Isp 10Nov170:00.00
/usr/sbin/dhcrelay -i vlan1565 192.0.2.194 192.0.2.196
_dhc
dhcrelay multiple instances possible bug
Hi there, many years that i don't use this ml. I'm Riccardo writing from Spain, nice to meet you guys. First of all, many compliments for the exceptional hard work that you've done in the OpenBSD development. Just, thank you. Next a possible bug: In the OpenBSD dhcrelay(8) implementation i cannot find an option to specify different interfaces in a single daemon instance, try to image a router with multiple vlans and a dhcpd server in other machine in an internal service dedicated routed ip network segment. The first instance is executed by the command: rcctl enable dhcrelay rcctl set dhcrelay flags "-i vlanxxx DST_ADDR" The second one i've done this workaround: cd /etc/rc.d cp -p dhcrelay dhcrelay_second rcctl enable dhcrelay_second rcctl set dhcrelay_second flags "-i vlanyyy DST_ADDR" Now if i open a tcpdump session in the router and in the server and i configure correctly the dhcpd in the server i notice that traffic from the dhcrelay_second to the dhclient host in the vlanyyy isn't correctly forwarded. And it is not a pf problem. The strangeness is that if i don't execute the relay from rcctl but i execute with: dhcrelay_second -d -i vlanyyy DST_ADDR it works like a charm. If you want more debug or pcap files or access to the machines there's no problem at all. Thank you to spend your time, nice regards, RG -- Name: Riccardo Giuntoli Email: tag...@gmail.com Location: Canyelles, BCN, España PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net
Re: dhcrelay between rdomains
Am 15.06.2018 10:27 schrieb Holger Glaess: ist see the forwarded bootreqest from dhcrelay but it is not possible , for me , to shift this reqest to an other rdom . just lift the outgoing (directed) request from dhcrelay with pf? -- pb
dhcrelay between rdomains
hi how can i forward the bootrequest from dhcrelay that listen in rdom 5 , example , to rdom 0 where my dhcpd server listen ? ist see the forwarded bootreqest from dhcrelay but it is not possible , for me , to shift this reqest to an other rdom . holger
Re: dhcrelay broken after Apr 5
> On 05.07.2017, at 11:50, Kapetanakis Giannis > wrote: > > On 05/07/17 12:45, Reyk Floeter wrote: >> >>> On 05.07.2017, at 11:41, Kapetanakis Giannis >>> wrote: >>> >>> On 04/07/17 19:09, Reyk Floeter wrote: >>>> Could you try again with the attached diff? It doesn't change >>>> behavior but it adds some chatty logging when a packet is rejected. >>>> Maybe it helps to find the issue. >>>> >>>> Reyk >>> >>> I've send the bug report as detailed as I could. >>> >> >> Thanks, now it is a good bug report and I think it helps to find the issue >> with carp+dhcrelay. >> >> You had a typo in the email subject ;-) >> >>> In a few words, applying your diff gave me these: >>> Jul 5 11:53:09 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 >>> Jul 5 11:53:09 dhcrelay[68565]: receive_packet:457: decode_hw_header >>> failed, len 364 >>> Jul 5 11:53:10 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 >>> Jul 5 11:53:10 dhcrelay[68565]: receive_packet:457: decode_hw_header >>> failed, len 364 >>> >> >> Reyk >> > > oops :)) > > sorry for that, do you want me to send it again with the correct subject so > it's archived ok? > > G > No, no, it's fine. The content of the mail is more important. Reyk
Re: dhcrelay broken after Apr 5
On 05/07/17 12:45, Reyk Floeter wrote: > >> On 05.07.2017, at 11:41, Kapetanakis Giannis >> wrote: >> >> On 04/07/17 19:09, Reyk Floeter wrote: >>> Could you try again with the attached diff? It doesn't change >>> behavior but it adds some chatty logging when a packet is rejected. >>> Maybe it helps to find the issue. >>> >>> Reyk >> >> I've send the bug report as detailed as I could. >> > > Thanks, now it is a good bug report and I think it helps to find the issue > with carp+dhcrelay. > > You had a typo in the email subject ;-) > >> In a few words, applying your diff gave me these: >> Jul 5 11:53:09 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 >> Jul 5 11:53:09 dhcrelay[68565]: receive_packet:457: decode_hw_header >> failed, len 364 >> Jul 5 11:53:10 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 >> Jul 5 11:53:10 dhcrelay[68565]: receive_packet:457: decode_hw_header >> failed, len 364 >> > > Reyk > oops :)) sorry for that, do you want me to send it again with the correct subject so it's archived ok? G
Re: dhcrelay broken after Apr 5
> On 05.07.2017, at 11:41, Kapetanakis Giannis > wrote: > > On 04/07/17 19:09, Reyk Floeter wrote: >> Could you try again with the attached diff? It doesn't change >> behavior but it adds some chatty logging when a packet is rejected. >> Maybe it helps to find the issue. >> >> Reyk > > I've send the bug report as detailed as I could. > Thanks, now it is a good bug report and I think it helps to find the issue with carp+dhcrelay. You had a typo in the email subject ;-) > In a few words, applying your diff gave me these: > Jul 5 11:53:09 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 > Jul 5 11:53:09 dhcrelay[68565]: receive_packet:457: decode_hw_header failed, > len 364 > Jul 5 11:53:10 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 > Jul 5 11:53:10 dhcrelay[68565]: receive_packet:457: decode_hw_header failed, > len 364 > Reyk
Re: dhcrelay broken after Apr 5
On 04/07/17 19:09, Reyk Floeter wrote: > Could you try again with the attached diff? It doesn't change > behavior but it adds some chatty logging when a packet is rejected. > Maybe it helps to find the issue. > > Reyk I've send the bug report as detailed as I could. In a few words, applying your diff gave me these: Jul 5 11:53:09 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 Jul 5 11:53:09 dhcrelay[68565]: receive_packet:457: decode_hw_header failed, len 364 Jul 5 11:53:10 dhcrelay[68565]: decode_hw_header:229: invalid htype 0 Jul 5 11:53:10 dhcrelay[68565]: receive_packet:457: decode_hw_header failed, len 364 G
Re: dhcrelay broken after Apr 5
On 04/07/17 19:09, Reyk Floeter wrote:
> First of all, please send a proper bug reports to bugs@, not misc.
> "It used to work but now it doesn't" is not very helpful.
>
> Could you share your actual configuration or, even better, provide a
> simplified way to reproduce your problem? rzalamena, me, and some
> other people have tested different setups but you seem to have an
> interestingly complex configuration.
>
> The new code has more validation, so it might be that it rightfully or
> wrongfully rejects packets that have been accepted before.
>
> Could you try again with the attached diff? It doesn't change
> behavior but it adds some chatty logging when a packet is rejected.
> Maybe it helps to find the issue.
>
> Reyk
Hi and thanks for the answer.
I would have send a better report if I could debug it.
-d does not produce any messages.
Also I'm not sure how to reproduce it. It just happened after the upgrade
and it happens in a random way... Not all users and not on all vlans.
I will try the patch and send a report to @bugs
G
> Index: usr.sbin/dhcrelay/bpf.c
> ===
> RCS file: /cvs/src/usr.sbin/dhcrelay/bpf.c,v
> retrieving revision 1.19
> diff -u -p -u -p -r1.19 bpf.c
> --- usr.sbin/dhcrelay/bpf.c 19 Apr 2017 05:36:12 - 1.19
> +++ usr.sbin/dhcrelay/bpf.c 4 Jul 2017 16:01:29 -
> @@ -349,11 +349,17 @@ send_packet(struct interface_info *inter
>
> /* Assemble the headers... */
> if ((bufp = assemble_hw_header(buf, sizeof(buf), 0, pc,
> - interface->hw_address.htype)) == -1)
> + interface->hw_address.htype)) == -1) {
> + log_warnx("%s:%d: assemble_hw_header failed, len %zu",
> + __func__, __LINE__, len);
> goto done;
> + }
> if ((bufp = assemble_udp_ip_header(buf, sizeof(buf), bufp, pc,
> - (unsigned char *)raw, len)) == -1)
> + (unsigned char *)raw, len)) == -1) {
> + log_warnx("%s:%d: assemble_udp_ip_header failed,"
> + " offset %zd len %zu", __func__, __LINE__, bufp, len);
> goto done;
> + }
>
> /* Fire it off */
> iov[0].iov_base = (char *)buf;
> @@ -447,6 +453,9 @@ receive_packet(struct interface_info *in
>* skip this packet.
>*/
> if (offset < 0) {
> + log_warnx("%s:%d: decode_hw_header failed,"
> + " len %zu", __func__, __LINE__,
> + interface->rbuf_len);
> interface->rbuf_offset += hdr.bh_caplen;
> continue;
> }
> @@ -457,6 +466,9 @@ receive_packet(struct interface_info *in
>
> /* If the IP or UDP checksum was bad, skip the packet... */
> if (offset < 0) {
> + log_warnx("%s:%d: decode_udp_ip_header failed,"
> + " offset %zd len %zu", __func__, __LINE__,
> + offset, interface->rbuf_len);
> interface->rbuf_offset += hdr.bh_caplen;
> continue;
> }
> @@ -470,6 +482,10 @@ receive_packet(struct interface_info *in
>* life, though).
>*/
> if (hdr.bh_caplen > len) {
> + log_warnx("%s:%d: XXX shouldn't happen in real life,"
> + " caplen %u > len %zu", __func__, __LINE__,
> + hdr.bh_caplen, len);
> +
> interface->rbuf_offset += hdr.bh_caplen;
> continue;
> }
> Index: usr.sbin/dhcrelay/packet.c
> ===
> RCS file: /cvs/src/usr.sbin/dhcrelay/packet.c,v
> retrieving revision 1.14
> diff -u -p -u -p -r1.14 packet.c
> --- usr.sbin/dhcrelay/packet.c5 Apr 2017 14:40:56 - 1.14
> +++ usr.sbin/dhcrelay/packet.c4 Jul 2017 16:01:29 -
> @@ -104,8 +104,12 @@ assemble_hw_header(unsigned char *buf, s
>
> switch (intfhtype) {
> case HTYPE_ETHER:
> - if (buflen < offset + ETHER_HDR_LEN)
> + if (buflen < offset + ETHER_HDR_LEN) {
> + log_warnx("%s:%d: short ether hdr buflen %zu < %zu",
> + __func__, __LINE__,
> + buflen, offset + ETHER_HDR_LEN);
> return (-1);
> + }
>
> /* Use the supplied addr
Re: dhcrelay broken after Apr 5
Hi,
On Tue, Jul 04, 2017 at 02:41:30PM +0300, Kapetanakis Giannis wrote:
> Hi,
>
> Just upgraded a set of my firewalls that also do dhcrelay to -current.
>
> The program stopped working ok. Some dhcp requests where being forwarded some
> not.
>
> tcpdump was showing the request on internal interface but I couldn't see the
> request being forwarded on the external interface.
> For some vlans the relay was working for some not.
>
> I've located the problem to this commit:
> http://marc.info/?l=openbsd-cvs&m=149140326301074&w=2
>
> Reverting back to:
> bpf.c,v 1.17
> packet.c,v 1.13
> dhcpd.h,v 1.22 2017/04/04
>
> everything was ok again.
>
> My setup is (trunk - on one firewall) - Vlans - carp - dhcrelay
> 28 vlans, 28 carps, 18 dhcrelay, 30 bpf devices
>
First of all, please send a proper bug reports to bugs@, not misc.
"It used to work but now it doesn't" is not very helpful.
Could you share your actual configuration or, even better, provide a
simplified way to reproduce your problem? rzalamena, me, and some
other people have tested different setups but you seem to have an
interestingly complex configuration.
The new code has more validation, so it might be that it rightfully or
wrongfully rejects packets that have been accepted before.
Could you try again with the attached diff? It doesn't change
behavior but it adds some chatty logging when a packet is rejected.
Maybe it helps to find the issue.
Reyk
Index: usr.sbin/dhcrelay/bpf.c
===
RCS file: /cvs/src/usr.sbin/dhcrelay/bpf.c,v
retrieving revision 1.19
diff -u -p -u -p -r1.19 bpf.c
--- usr.sbin/dhcrelay/bpf.c 19 Apr 2017 05:36:12 - 1.19
+++ usr.sbin/dhcrelay/bpf.c 4 Jul 2017 16:01:29 -
@@ -349,11 +349,17 @@ send_packet(struct interface_info *inter
/* Assemble the headers... */
if ((bufp = assemble_hw_header(buf, sizeof(buf), 0, pc,
- interface->hw_address.htype)) == -1)
+ interface->hw_address.htype)) == -1) {
+ log_warnx("%s:%d: assemble_hw_header failed, len %zu",
+ __func__, __LINE__, len);
goto done;
+ }
if ((bufp = assemble_udp_ip_header(buf, sizeof(buf), bufp, pc,
- (unsigned char *)raw, len)) == -1)
+ (unsigned char *)raw, len)) == -1) {
+ log_warnx("%s:%d: assemble_udp_ip_header failed,"
+ " offset %zd len %zu", __func__, __LINE__, bufp, len);
goto done;
+ }
/* Fire it off */
iov[0].iov_base = (char *)buf;
@@ -447,6 +453,9 @@ receive_packet(struct interface_info *in
* skip this packet.
*/
if (offset < 0) {
+ log_warnx("%s:%d: decode_hw_header failed,"
+ " len %zu", __func__, __LINE__,
+ interface->rbuf_len);
interface->rbuf_offset += hdr.bh_caplen;
continue;
}
@@ -457,6 +466,9 @@ receive_packet(struct interface_info *in
/* If the IP or UDP checksum was bad, skip the packet... */
if (offset < 0) {
+ log_warnx("%s:%d: decode_udp_ip_header failed,"
+ " offset %zd len %zu", __func__, __LINE__,
+ offset, interface->rbuf_len);
interface->rbuf_offset += hdr.bh_caplen;
continue;
}
@@ -470,6 +482,10 @@ receive_packet(struct interface_info *in
* life, though).
*/
if (hdr.bh_caplen > len) {
+ log_warnx("%s:%d: XXX shouldn't happen in real life,"
+ " caplen %u > len %zu", __func__, __LINE__,
+ hdr.bh_caplen, len);
+
interface->rbuf_offset += hdr.bh_caplen;
continue;
}
Index: usr.sbin/dhcrelay/packet.c
===
RCS file: /cvs/src/usr.sbin/dhcrelay/packet.c,v
retrieving revision 1.14
diff -u -p -u -p -r1.14 packet.c
--- usr.sbin/dhcrelay/packet.c 5 Apr 2017 14:40:56 - 1.14
+++ usr.sbin/dhcrelay/packet.c 4 Jul 2017 16:01:29 -
@@ -104,8 +104,12 @@ assemble_hw_header(unsigned char *buf, s
switch (intfhtype) {
case HTYPE_ETHER:
- if (buflen < offset + ETHER_HDR_LEN)
+ if (buflen < offset + ETHER_HDR_LEN) {
+ log_warnx("%s:%d: short ether hdr buflen %zu < %zu",
+ __func__, __LINE__,
+
dhcrelay broken after Apr 5
Hi, Just upgraded a set of my firewalls that also do dhcrelay to -current. The program stopped working ok. Some dhcp requests where being forwarded some not. tcpdump was showing the request on internal interface but I couldn't see the request being forwarded on the external interface. For some vlans the relay was working for some not. I've located the problem to this commit: http://marc.info/?l=openbsd-cvs&m=149140326301074&w=2 Reverting back to: bpf.c,v 1.17 packet.c,v 1.13 dhcpd.h,v 1.22 2017/04/04 everything was ok again. My setup is (trunk - on one firewall) - Vlans - carp - dhcrelay 28 vlans, 28 carps, 18 dhcrelay, 30 bpf devices regards, Giannis
Re: rdomain and dhcrelay
> Am 05/09/16 um 08:20 schrieb Holger Glaess: >> hi >> >> is there an possiblity to forward dhcp request from >> an rdomain X to the runing dhcp server in rdomain 0 ? >> >> >> if i start the dhcrelay -i em1 192.168.131.250, >> >> i see that he forward the request but never reach the server. >> >> the clients in rdoamin 0 works with the dhcp server. >> >> or it is need to modify the dhcrelay with an option , >> >> route -n -T 2 exec dhcrelay -i em1 -V 0 192.168.131.250 >> >> ? >> em1 is part of rdomain 2. >> 192.168.131.xxx ist part of rdomain 0 >> >> holger >> > > You can shove the packets to the correct rdomain with pf or pair(4) > maybe of help: > > "Add pair(4), a vether-based virtual Ethernet driver to interconnect > rdomains and bridges on the local system." > > http://www.openbsd.org/plus59.html > > > HTH, > Marc > > Hi , i know pair because it breaks the isolation of the rdomain. and forward a forward req. from dhcrelay with pf it´s ugly. ok i will try. thanks holger
Re: rdomain and dhcrelay
Am 05/09/16 um 08:20 schrieb Holger Glaess: > hi > > is there an possiblity to forward dhcp request from > an rdomain X to the runing dhcp server in rdomain 0 ? > > > if i start the dhcrelay -i em1 192.168.131.250, > > i see that he forward the request but never reach the server. > > the clients in rdoamin 0 works with the dhcp server. > > or it is need to modify the dhcrelay with an option , > > route -n -T 2 exec dhcrelay -i em1 -V 0 192.168.131.250 > > ? > em1 is part of rdomain 2. > 192.168.131.xxx ist part of rdomain 0 > > holger > You can shove the packets to the correct rdomain with pf or pair(4) maybe of help: "Add pair(4), a vether-based virtual Ethernet driver to interconnect rdomains and bridges on the local system." http://www.openbsd.org/plus59.html HTH, Marc
rdomain and dhcrelay
hi is there an possiblity to forward dhcp request from an rdomain X to the runing dhcp server in rdomain 0 ? if i start the dhcrelay -i em1 192.168.131.250, i see that he forward the request but never reach the server. the clients in rdoamin 0 works with the dhcp server. or it is need to modify the dhcrelay with an option , route -n -T 2 exec dhcrelay -i em1 -V 0 192.168.131.250 ? em1 is part of rdomain 2. 192.168.131.xxx ist part of rdomain 0 holger
Re: dhcrelay: send_packet: No buffer space available
On 20/02/16 13:52, Stuart Henderson wrote:
Are the carp interfaces "up" (i.e. master) when you see these messages?
Yes always.
On both firewalls I have net.inet.carp.log=3 and I haven't logged any
carp up/down - MASTER/BACKUP transition messages.
On the other hand, on backup firewall I just noticed relevant? messages
but on different times and no other sign that it became the MASTER.
Feb 9 12:58:54 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 9 16:41:58 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 11 10:16:37 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 11 18:32:21 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 15 10:31:01 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 16 12:06:10 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 17 16:45:06 backup_fw2 dhcrelay: send_packet: Network is unreachable
Feb 18 09:19:11 backup_fw2 dhcrelay: send_packet: Network is unreachable
So it looks it's related to carp because the backup fw shouldn't have
relay the dhcp requests from clients but for some unknown reason it did...
How can I make the warning() to print carp/interface status?
I did the following to print interface name:
diff -u -p -r1.10 bpf.c
--- bpf.c 7 Feb 2016 00:49:28 - 1.10
+++ bpf.c 20 Feb 2016 12:53:02 -
@@ -299,7 +299,7 @@ send_packet(struct interface_info *inter
result = writev(interface->wfdesc, iov, 2);
done:
if (result == -1)
- warning("send_packet: %m");
+ warning("send_packet: %m on %s", interface->name);
return (result);
}
Thanks!
G
Re: dhcrelay: send_packet: No buffer space available
On 2016-02-18, Kapetanakis Giannis wrote: > On 12/02/16 18:56, Stuart Henderson wrote: >> On 2016-02-12, Kapetanakis Giannis wrote: >>> Hi, >>> >>> I have a carped firewall which is using dhcrelay to forward dhcp >>> requests to another carped dhcp server. >>> After upgrade to Feb 4 snapshot I'm seeing these in my logs: >> What version were you running before? >> >> To establish whether it's a dhcrelay problem or something to do with carp >> can you try dhcrelay from slightly older source e.g. 'cvs up -D 2016/02/01'? >> > > I went back to 2016/02/01 and 2016/01/12 (packet.c) and I have the same > problem > so it doesn't seem like a dhcrelay problem. > > I changed it to print the interfaces > Feb 17 18:04:28 dhcrelay: send_packet: No buffer space available on carp63 > Feb 18 09:16:35 dhcrelay: send_packet: No buffer space available on carp32 > Feb 18 09:27:45 dhcrelay: send_packet: No buffer space available on carp32 > but there is no network/routing problem. > > Setup is trunk (lacp) - vlans - carps - dhcrelay for internal > trunk (lacp) / nat for external > > ospf in (passive on carps) / out on ext trunk. > > Any way to debug this further? > > thanks, > > Giannis > Are the carp interfaces "up" (i.e. master) when you see these messages?
Re: dhcrelay: send_packet: No buffer space available
On 18/02/16 15:52, Kapetanakis Giannis wrote: On 18/02/16 13:22, Peter Hessler wrote: How many bpf devices do you have? You may need to create more. I have 20 bpf devices, 27 vlan interfaces, 27 carp interfaces, 17 dhcrelay processes. wasn't there a message when bpf devides were short? Anyway I pushed it to 30 bpf devices and see how it goes. G Unfortunately that wasn't the problem... Feb 19 09:10:42 dhcrelay: send_packet: No buffer space available carp48 # fstat|grep bpf|wc -l 19 any more ideas? thanks G
Re: dhcrelay: send_packet: No buffer space available
On 18/02/16 13:22, Peter Hessler wrote: On 2016 Feb 18 (Thu) at 12:25:07 +0200 (+0200), Kapetanakis Giannis wrote: :On 12/02/16 18:56, Stuart Henderson wrote: :>On 2016-02-12, Kapetanakis Giannis wrote: :>>Hi, :>> :>>I have a carped firewall which is using dhcrelay to forward dhcp :>>requests to another carped dhcp server. :>>After upgrade to Feb 4 snapshot I'm seeing these in my logs: :>What version were you running before? :> :>To establish whether it's a dhcrelay problem or something to do with carp :>can you try dhcrelay from slightly older source e.g. 'cvs up -D 2016/02/01'? :> : :I went back to 2016/02/01 and 2016/01/12 (packet.c) and I have the same :problem :so it doesn't seem like a dhcrelay problem. : :I changed it to print the interfaces :Feb 17 18:04:28 dhcrelay: send_packet: No buffer space available on carp63 :Feb 18 09:16:35 dhcrelay: send_packet: No buffer space available on carp32 :Feb 18 09:27:45 dhcrelay: send_packet: No buffer space available on carp32 :but there is no network/routing problem. : :Setup is trunk (lacp) - vlans - carps - dhcrelay for internal :trunk (lacp) / nat for external : :ospf in (passive on carps) / out on ext trunk. : :Any way to debug this further? : :thanks, : :Giannis : How many bpf devices do you have? You may need to create more. I have 20 bpf devices, 27 vlan interfaces, 27 carp interfaces, 17 dhcrelay processes. wasn't there a message when bpf devides were short? Anyway I pushed it to 30 bpf devices and see how it goes. G
Re: dhcrelay: send_packet: No buffer space available
On 2016 Feb 18 (Thu) at 12:25:07 +0200 (+0200), Kapetanakis Giannis wrote: :On 12/02/16 18:56, Stuart Henderson wrote: :>On 2016-02-12, Kapetanakis Giannis wrote: :>>Hi, :>> :>>I have a carped firewall which is using dhcrelay to forward dhcp :>>requests to another carped dhcp server. :>>After upgrade to Feb 4 snapshot I'm seeing these in my logs: :>What version were you running before? :> :>To establish whether it's a dhcrelay problem or something to do with carp :>can you try dhcrelay from slightly older source e.g. 'cvs up -D 2016/02/01'? :> : :I went back to 2016/02/01 and 2016/01/12 (packet.c) and I have the same :problem :so it doesn't seem like a dhcrelay problem. : :I changed it to print the interfaces :Feb 17 18:04:28 dhcrelay: send_packet: No buffer space available on carp63 :Feb 18 09:16:35 dhcrelay: send_packet: No buffer space available on carp32 :Feb 18 09:27:45 dhcrelay: send_packet: No buffer space available on carp32 :but there is no network/routing problem. : :Setup is trunk (lacp) - vlans - carps - dhcrelay for internal :trunk (lacp) / nat for external : :ospf in (passive on carps) / out on ext trunk. : :Any way to debug this further? : :thanks, : :Giannis : How many bpf devices do you have? You may need to create more. -- I'm a creationist; I refuse to believe that I could have evolved from man.
Re: dhcrelay: send_packet: No buffer space available
On 12/02/16 18:56, Stuart Henderson wrote: On 2016-02-12, Kapetanakis Giannis wrote: Hi, I have a carped firewall which is using dhcrelay to forward dhcp requests to another carped dhcp server. After upgrade to Feb 4 snapshot I'm seeing these in my logs: What version were you running before? To establish whether it's a dhcrelay problem or something to do with carp can you try dhcrelay from slightly older source e.g. 'cvs up -D 2016/02/01'? I went back to 2016/02/01 and 2016/01/12 (packet.c) and I have the same problem so it doesn't seem like a dhcrelay problem. I changed it to print the interfaces Feb 17 18:04:28 dhcrelay: send_packet: No buffer space available on carp63 Feb 18 09:16:35 dhcrelay: send_packet: No buffer space available on carp32 Feb 18 09:27:45 dhcrelay: send_packet: No buffer space available on carp32 but there is no network/routing problem. Setup is trunk (lacp) - vlans - carps - dhcrelay for internal trunk (lacp) / nat for external ospf in (passive on carps) / out on ext trunk. Any way to debug this further? thanks, Giannis
Re: dhcrelay: send_packet: No buffer space available
On 2016-02-13, Kapetanakis Giannis wrote: > On 12/02/16 18:56, Stuart Henderson wrote: >> On 2016-02-12, Kapetanakis Giannis wrote: >>> Hi, >>> >>> I have a carped firewall which is using dhcrelay to forward dhcp >>> requests to another carped dhcp server. >>> After upgrade to Feb 4 snapshot I'm seeing these in my logs: >> What version were you running before? >> >> To establish whether it's a dhcrelay problem or something to do with carp >> can you try dhcrelay from slightly older source e.g. 'cvs up -D 2016/02/01'? >> > > The previous version was from July 2015 so it was far away from now. So there are a lot of changea to networking in that timeframe, but only a few changes to dhcrelay. To narrow it down and establish whether it's a dhcrelay problem or something to do with carp can you try dhcrelay from slightly older source e.g. 'cvs up -D 2016/02/01'? > I guess it will not work with current kernel and pledge(2), tame(2) > changes correct? This isn't anything to do with pledge. I wouldn't expect old network-related binaries to work on -current due to the network stack changes though.
Re: dhcrelay: send_packet: No buffer space available
On 12/02/16 18:56, Stuart Henderson wrote: On 2016-02-12, Kapetanakis Giannis wrote: Hi, I have a carped firewall which is using dhcrelay to forward dhcp requests to another carped dhcp server. After upgrade to Feb 4 snapshot I'm seeing these in my logs: What version were you running before? To establish whether it's a dhcrelay problem or something to do with carp can you try dhcrelay from slightly older source e.g. 'cvs up -D 2016/02/01'? The previous version was from July 2015 so it was far away from now. I guess it will not work with current kernel and pledge(2), tame(2) changes correct? G
Re: dhcrelay: send_packet: No buffer space available
On 2016-02-12, Kapetanakis Giannis wrote: > Hi, > > I have a carped firewall which is using dhcrelay to forward dhcp > requests to another carped dhcp server. > After upgrade to Feb 4 snapshot I'm seeing these in my logs: What version were you running before? To establish whether it's a dhcrelay problem or something to do with carp can you try dhcrelay from slightly older source e.g. 'cvs up -D 2016/02/01'?
Re: dhcrelay: send_packet: No buffer space available
On 02/12/16 12:15, Kapetanakis Giannis wrote: I have a carped firewall which is using dhcrelay to forward dhcp requests to another carped dhcp server. After upgrade to Feb 4 snapshot I'm seeing these in my logs: Feb 8 21:00:04 dhcrelay: send_packet: No buffer space available Feb 9 16:47:02 dhcrelay: send_packet: No buffer space available I've seen that message only when a link or interface is down but for some reason the machine still thinks that it's OK to route packets over it anyway. So I'd start with checking routing vs actually available links. -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
dhcrelay: send_packet: No buffer space available
Hi, I have a carped firewall which is using dhcrelay to forward dhcp requests to another carped dhcp server. After upgrade to Feb 4 snapshot I'm seeing these in my logs: Feb 8 21:00:04 dhcrelay: send_packet: No buffer space available Feb 9 16:47:02 dhcrelay: send_packet: No buffer space available Feb 9 18:43:50 dhcrelay: send_packet: No buffer space available Feb 10 10:00:14 dhcrelay: send_packet: No buffer space available Feb 10 12:34:02 dhcrelay: send_packet: No buffer space available Feb 10 18:05:02 dhcrelay: send_packet: No buffer space available Feb 10 20:19:02 dhcrelay: send_packet: No buffer space available Feb 10 23:10:05 dhcrelay: send_packet: No buffer space available Feb 11 23:30:09 dhcrelay: send_packet: No buffer space available Feb 12 11:48:52 dhcrelay: send_packet: No buffer space available Before I start pushing buttons I shouldn't, any recommendations? Thanks, G # netstat -m 460 mbufs in use: 450 mbufs allocated to data 5 mbufs allocated to packet headers 5 mbufs allocated to socket names and addresses 447/1968/6144 mbuf 2048 byte clusters in use (current/peak/max) 0/8/6144 mbuf 4096 byte clusters in use (current/peak/max) 0/8/6144 mbuf 8192 byte clusters in use (current/peak/max) 0/14/6146 mbuf 9216 byte clusters in use (current/peak/max) 0/10/6150 mbuf 12288 byte clusters in use (current/peak/max) 0/8/6144 mbuf 16384 byte clusters in use (current/peak/max) 0/8/6144 mbuf 65536 byte clusters in use (current/peak/max) 2184 Kbytes allocated to network (46% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines # vmstat -m Memory statistics by bucket size Size In Use Free Requests HighWater Couldfree 16 8868 256755361280 91 32 1760 11845863660 640 27 64 2484 12287496442 320 2545 128 4357 591116059 160112 256 5541821820217 80 1254 512 708 36 803977 40423 1024 171149 716381 20 497401 2048 129 5 218715 10 0 4096 2100 5 348328 5 2028 8192 210 2 4679 5 0 163847 0 12 5 0 32768 41 0 42 5 0 655361 03321986 5 0 2621441 0 1 5 0 5242881 0 1 5 0 Memory usage type by bucket size Size Type(s) 16 devbuf, pcb, rtable, ifaddr, UFS mount, dirhash, ACPI, ip_moptions, exec, VM swap, UVM amap, UVM aobj, USB, USB device, temp 32 devbuf, pcb, rtable, ifaddr, sem, dirhash, ACPI, in_multi, exec, UVM amap, USB, USB device, temp 64 devbuf, rtable, ifaddr, sysctl, vnodes, dirhash, ACPI, proc, in_multi, ether_multi, VM swap, UVM amap, USB, NDP, temp 128 devbuf, pcb, rtable, ifaddr, UFS mount, sem, dirhash, ACPI, NFS srvsock, ip_moptions, in_multi, pfkey data, UVM amap, USB, USB device, temp 256 devbuf, rtable, ifaddr, sysctl, ioctlops, iov, vnodes, shm, VM map, dirhash, ACPI, exec, UVM amap, USB, USB device 512 devbuf, ifaddr, ioctlops, iov, UFS mount, dirhash, ACPI, file desc, ttys, newblk, UVM amap, temp 1024 devbuf, pcb, ifaddr, sysctl, ioctlops, iov, mount, shm, proc, ttys, exec, UVM amap, crypto data, temp 2048 devbuf, ifaddr, ioctlops, iov, UFS mount, ACPI, VM swap, UVM amap, UVM aobj, temp 4096 devbuf, ifaddr, ioctlops, proc, ttys, UVM amap, memdesc, temp 8192 devbuf, ttys, pagedep, UVM amap, USB, temp 16384 devbuf, NFS daemon, MSDOSFS mount, temp 32768 devbuf, UFS quota, UFS mount, ISOFS mount, inodedep 65536 devbuf, temp 262144 VM swap 524288 VM swap Memory statistics by type Type Kern Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) devbuf 4695 10221K 10222K 78644K754610 0 16,32,64,128,256,512,1024,2048,4096,8192,16384,32768,65536 pcb6515K 16K 78644K134960 0 16,32,128,1024 rtable 111537K 52K 78644K 5613250 0 16,32,64,128,256 ifaddr 31642K 42K 78644K 3500 0 16,32,64,128,256,512,1024,2048,4096 sysctl 3 2K 2K 78644K30 0 64,256,1024 ioctlops 0 0K 4K 78644K418010 0 256,512,1024,2048,4096 iov 0 0K 2K 78644K 1420 0 256,512,1024,2048 mount 3 3K 3K 78644K30 0 1024 vnodes 127780K 81K 78644K 9958
Re: dhcrelay Can't find free bpf: No such file or directory
if i'm not mistaken, it's Berkeley Packet Filter.
I must do the same issue for dhcpd when i use many vlan interfaces and
PF :)
--
Cordialement,
Loïc BLOT, UNIX systems, security and network expert
http://www.unix-experience.fr
Le mardi 08 janvier 2013 à 20:39 +0100, Ulrich Drolshagen a écrit :
> Am 08.01.2013 19:48, schrieb Janne Johansson:
> > cd /dev
> > for i in $(jot 20 10); do ./MAKEDEV bpf${i} ; done
> > to make 20 more bpfs. Each tcpdump and dhcrelay will want one of their
> > own so you may need more dev-entries.
> Thank you, this did the trick. I really didn't know what "bpf" are and
> didn't think of devices.
> >
> >
> > 2013/1/8 Ulrich Drolshagen :
> >> Hi,
> >>
> >> I am running an openbsd router attached to several vlans. On one of them
> >> there is running a box with an isc-dhcp server.
> >> For one of the vlans I have started a dhcrelay to forward the dhcp
> >> broadcasts of the respective subnet to the server
> >>
> >> dhcrelay -i vlan5 172.16.1.4
> >>
> >> This is working fine for some time now. If I try to start it a second time,
> >> I get this:
> >>
> >> root:42# dhcrelay -d -i vlan6 172.16.1.4
> >> Can't find free bpf: No such file or directory
> >> Jan 8 18:33:05 router dhcrelay: Can't find free bpf: No such file or
> >> directory
> >> exiting.
> >>
> >> To my understanding dhcrelay should support whatever vlan requires
> >> forwarding the broadcasts. For me it does not make sense to only support
> >> just one subnet. Or am I missing something here?
> >>
> >> Thank you for looking into this
> >>
> >> Ulrich
> >>
> >> --
> >> http://www.ulrich-drolshagen.de
Re: dhcrelay Can't find free bpf: No such file or directory
On Tue, Jan 08, 2013 at 06:37:45PM +0100, Ulrich Drolshagen wrote: > Hi, > > I am running an openbsd router attached to several vlans. On one of > them there is running a box with an isc-dhcp server. > For one of the vlans I have started a dhcrelay to forward the dhcp > broadcasts of the respective subnet to the server > > dhcrelay -i vlan5 172.16.1.4 > > This is working fine for some time now. If I try to start it a > second time, I get this: > > root:42# dhcrelay -d -i vlan6 172.16.1.4 > Can't find free bpf: No such file or directory > Jan 8 18:33:05 router dhcrelay: Can't find free bpf: No such file > or directory > exiting. > > To my understanding dhcrelay should support whatever vlan requires > forwarding the broadcasts. For me it does not make sense to only > support just one subnet. Or am I missing something here? > > Thank you for looking into this > > Ulrich > > -- > http://www.ulrich-drolshagen.de > http://openbsd.org/report.html Ken
Re: dhcrelay Can't find free bpf: No such file or directory
Am 08.01.2013 19:48, schrieb Janne Johansson:
cd /dev
for i in $(jot 20 10); do ./MAKEDEV bpf${i} ; done
to make 20 more bpfs. Each tcpdump and dhcrelay will want one of their
own so you may need more dev-entries.
Thank you, this did the trick. I really didn't know what "bpf" are and
didn't think of devices.
2013/1/8 Ulrich Drolshagen :
Hi,
I am running an openbsd router attached to several vlans. On one of them
there is running a box with an isc-dhcp server.
For one of the vlans I have started a dhcrelay to forward the dhcp
broadcasts of the respective subnet to the server
dhcrelay -i vlan5 172.16.1.4
This is working fine for some time now. If I try to start it a second time,
I get this:
root:42# dhcrelay -d -i vlan6 172.16.1.4
Can't find free bpf: No such file or directory
Jan 8 18:33:05 router dhcrelay: Can't find free bpf: No such file or
directory
exiting.
To my understanding dhcrelay should support whatever vlan requires
forwarding the broadcasts. For me it does not make sense to only support
just one subnet. Or am I missing something here?
Thank you for looking into this
Ulrich
--
http://www.ulrich-drolshagen.de
--
http://www.ulrich-drolshagen.de
Re: dhcrelay Can't find free bpf: No such file or directory
cd /dev
for i in $(jot 20 10); do ./MAKEDEV bpf${i} ; done
to make 20 more bpfs. Each tcpdump and dhcrelay will want one of their
own so you may need more dev-entries.
2013/1/8 Ulrich Drolshagen :
> Hi,
>
> I am running an openbsd router attached to several vlans. On one of them
> there is running a box with an isc-dhcp server.
> For one of the vlans I have started a dhcrelay to forward the dhcp
> broadcasts of the respective subnet to the server
>
> dhcrelay -i vlan5 172.16.1.4
>
> This is working fine for some time now. If I try to start it a second time,
> I get this:
>
> root:42# dhcrelay -d -i vlan6 172.16.1.4
> Can't find free bpf: No such file or directory
> Jan 8 18:33:05 router dhcrelay: Can't find free bpf: No such file or
> directory
> exiting.
>
> To my understanding dhcrelay should support whatever vlan requires
> forwarding the broadcasts. For me it does not make sense to only support
> just one subnet. Or am I missing something here?
>
> Thank you for looking into this
>
> Ulrich
>
> --
> http://www.ulrich-drolshagen.de
>
--
May the most significant bit of your life be positive.
dhcrelay Can't find free bpf: No such file or directory
Hi, I am running an openbsd router attached to several vlans. On one of them there is running a box with an isc-dhcp server. For one of the vlans I have started a dhcrelay to forward the dhcp broadcasts of the respective subnet to the server dhcrelay -i vlan5 172.16.1.4 This is working fine for some time now. If I try to start it a second time, I get this: root:42# dhcrelay -d -i vlan6 172.16.1.4 Can't find free bpf: No such file or directory Jan 8 18:33:05 router dhcrelay: Can't find free bpf: No such file or directory exiting. To my understanding dhcrelay should support whatever vlan requires forwarding the broadcasts. For me it does not make sense to only support just one subnet. Or am I missing something here? Thank you for looking into this Ulrich -- http://www.ulrich-drolshagen.de
Re: dhcrelay and rc.d in OpenBSD 5.0
On 2011-11-09, Antoine Jacoutot wrote: > On Wed, Nov 09, 2011 at 05:36:54PM +0100, Comhte wrote: >> Hi, >> >> In 4.9, i used to start dhcrelay using /etc/rc.local like this: >> >> /usr/sbin/dhcrelay -i vlan2 10.0.45.11 >> /usr/sbin/dhcrelay -i vlan5 10.0.45.11 >> /usr/sbin/dhcrelay -i vlan7 10.0.45.11 >> /usr/sbin/dhcrelay -i vlan100 10.11.1.8 10.22.1.8 >> /usr/sbin/dhcrelay -i vlan101 10.11.1.8 10.22.1.8 >> >> but now with 5.0, i saw that there was a script /etc/rc.d/dhcrelay >> >> so, what is now the best way to set up all my dhcp relays ? > > You can still use rc.local(8) for that, it's easier when you have multiple > dhcrelay running. > FWIW, the same goes if you want to run ftp-proxy for both v4 and v6.
Re: dhcrelay and rc.d in OpenBSD 5.0
On Wed, Nov 09, 2011 at 05:36:54PM +0100, Comhte wrote: Hi, In 4.9, i used to start dhcrelay using /etc/rc.local like this: /usr/sbin/dhcrelay -i vlan2 10.0.45.11 /usr/sbin/dhcrelay -i vlan5 10.0.45.11 /usr/sbin/dhcrelay -i vlan7 10.0.45.11 /usr/sbin/dhcrelay -i vlan100 10.11.1.8 10.22.1.8 /usr/sbin/dhcrelay -i vlan101 10.11.1.8 10.22.1.8 but now with 5.0, i saw that there was a script /etc/rc.d/dhcrelay so, what is now the best way to set up all my dhcp relays ? Le 09/11/2011 18:59, Antoine Jacoutot a icrit : You can still use rc.local(8) for that, it's easier when you have multiple dhcrelay running. Ok, thanks a lot.
Re: dhcrelay and rc.d in OpenBSD 5.0
On Wed, Nov 09, 2011 at 05:36:54PM +0100, Comhte wrote: Hi, In 4.9, i used to start dhcrelay using /etc/rc.local like this: /usr/sbin/dhcrelay -i vlan2 10.0.45.11 /usr/sbin/dhcrelay -i vlan5 10.0.45.11 /usr/sbin/dhcrelay -i vlan7 10.0.45.11 /usr/sbin/dhcrelay -i vlan100 10.11.1.8 10.22.1.8 /usr/sbin/dhcrelay -i vlan101 10.11.1.8 10.22.1.8 but now with 5.0, i saw that there was a script /etc/rc.d/dhcrelay so, what is now the best way to set up all my dhcp relays ? > Le 09/11/2011 18:59, Antoine Jacoutot a icrit : You can still use rc.local(8) for that, it's easier when you have multiple dhcrelay running. Ok, thanks a lot.
Re: dhcrelay and rc.d in OpenBSD 5.0
On Wed, Nov 09, 2011 at 05:36:54PM +0100, Comhte wrote: > Hi, > > In 4.9, i used to start dhcrelay using /etc/rc.local like this: > > /usr/sbin/dhcrelay -i vlan2 10.0.45.11 > /usr/sbin/dhcrelay -i vlan5 10.0.45.11 > /usr/sbin/dhcrelay -i vlan7 10.0.45.11 > /usr/sbin/dhcrelay -i vlan100 10.11.1.8 10.22.1.8 > /usr/sbin/dhcrelay -i vlan101 10.11.1.8 10.22.1.8 > > but now with 5.0, i saw that there was a script /etc/rc.d/dhcrelay > > so, what is now the best way to set up all my dhcp relays ? You can still use rc.local(8) for that, it's easier when you have multiple dhcrelay running. -- Antoine
dhcrelay and rc.d in OpenBSD 5.0
Hi, In 4.9, i used to start dhcrelay using /etc/rc.local like this: /usr/sbin/dhcrelay -i vlan2 10.0.45.11 /usr/sbin/dhcrelay -i vlan5 10.0.45.11 /usr/sbin/dhcrelay -i vlan7 10.0.45.11 /usr/sbin/dhcrelay -i vlan100 10.11.1.8 10.22.1.8 /usr/sbin/dhcrelay -i vlan101 10.11.1.8 10.22.1.8 but now with 5.0, i saw that there was a script /etc/rc.d/dhcrelay so, what is now the best way to set up all my dhcp relays ? Thanks
Re: VPN Gateway, DHCP over IPSec, dhcrelay on enc0?
2010/5/23 Martin Pelikan : > 2010/5/22, Don Reis : >> I have the idea that to make DHCP work over IPSec on my VPN gateway, I have >> to make dhcpd listen on lo0, and then have dhcrelay listen on enc0 and relay >> to lo0. (dhcpd runs on same machine) >> >> Why doesn't dhcrelay find enc0? And Is this the proper way to make this >> work? >> > > This is where bridge(4) and the new vether(4) device comes handy... > Set it up to listen on vether, set the proposed DHCP server IP address > to vether too and bridge it (or find another solution) Just to make sure I understand you correctly, you are suggesting I make dhcpd listen on vether0 (ip address of dhcpd server on vether0) and then add enc0 and vether0 to bridge0? Also, just for my knowledge, why doesn't dhcrelay like enc0 being fed to it? It seems from the man page that this is a supported configuration. > > -- > Martin Pelikan
Re: VPN Gateway, DHCP over IPSec, dhcrelay on enc0?
2010/5/22, Don Reis : > I have the idea that to make DHCP work over IPSec on my VPN gateway, I have > to make dhcpd listen on lo0, and then have dhcrelay listen on enc0 and relay > to lo0. (dhcpd runs on same machine) > > Why doesn't dhcrelay find enc0? And Is this the proper way to make this > work? > This is where bridge(4) and the new vether(4) device comes handy... Set it up to listen on vether, set the proposed DHCP server IP address to vether too and bridge it (or find another solution) -- Martin Pelikan
VPN Gateway, DHCP over IPSec, dhcrelay on enc0?
I have the idea that to make DHCP work over IPSec on my VPN gateway, I have to make dhcpd listen on lo0, and then have dhcrelay listen on enc0 and relay to lo0. (dhcpd runs on same machine) It seems from the dhcrelay man page that this is possible and that the -o switch is even enabled by default when using an enc interface, to supply the necessary relay agent information. However, upon trying to execute dhcrelay -do -i enc0 127.0.0.1, I get "enc0: not found" and it exits. ifconfig shows enc0 is up. Why doesn't dhcrelay find enc0? And Is this the proper way to make this work? I am working under the assumption that dhcrelay and dhcpd both support RFC 3046.
dhcrelay barfing on reboot
Running 4.6-stable:
$ dmesg
OpenBSD 4.6-stable (GENERIC) #0: Wed Nov 25 08:10:07 EST 2009
...
Attempting to enable dhcrelay to run via rc.conf.local is barfing.
Specifically running the daemon interactively seems happy:
$ sudo dhcrelay -i fxp3 192.168.100.6
$
$ ps -ax | grep dhcrelay
31341 ?? Is 0:00.00 dhcrelay -i fxp3 192.168.100.6
$
Subsequently, my DHCP server now responds to DHCP requests forwarded
from the segment on fxp3. Life is good.
However attempting to configure for start upon reboot fails:
$ cat /etc/rc.conf.local | grep dhcrelay
dhcrelay_flags="-i fxp3 192.168.100.6"
*INSERT REBOOT HERE*
$ ps -ax | grep dhcrelay
$
$ more /var/log/daemon | grep dhcrelay
Jan 4 16:11:49 fw01 dhcrelay: fxp3: host unknown
Jan 4 16:11:49 fw01 dhcrelay: no interface given
Jan 4 16:11:49 fw01 dhcrelay: exiting.
Jan 4 16:11:57 fw01 dhcrelay: Can't find free bpf: Permission denied
Jan 4 16:11:57 fw01 dhcrelay: exiting.
Jan 4 16:12:12 fw01 dhcrelay: Can't find free bpf: Permission denied
Jan 4 16:12:12 fw01 dhcrelay: exiting.
Jan 4 16:14:25 fw01 dhcrelay: Can't find free bpf: Permission denied
Jan 4 16:14:25 fw01 dhcrelay: exiting.
Jan 4 17:00:54 fw01 dhcrelay: Can't find free bpf: Permission denied
Jan 4 17:00:54 fw01 dhcrelay: exiting.
Jan 4 17:12:58 fw01 dhcrelay: connect: Address already in use
Jan 4 17:12:58 fw01 dhcrelay: exiting.
$
Haven't found much online about others dealing with this. Man pages for
dhcrelay, rc.conf.local, etc... haven't yielded much either.
Any pointers and or RTFM suggestions appreciated.
Entire dmesg below sig
-sc
$ dmesg
OpenBSD 4.6-stable (GENERIC) #0: Wed Nov 25 08:10:07 EST 2009
r...@fw01.caesare.com:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel(R) Pentium(R) III CPU family 1266MHz ("GenuineIntel"
686-class) 1.27 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,
MMX,FXSR,SSE
real mem = 1610166272 (1535MB)
avail mem = 1547108352 (1475MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/31/99, BIOS32 rev. 0 @ 0xf,
SMBIOS rev. 2.3 @ 0xf7ce8 (23 entries)
bios0: vendor Compaq version "P21" date 06/13/2001
bios0: Compaq ProLiant DL360
acpi0 at bios0: rev 0, can't enable ACPI
mpbios0 at bios0: Intel MP Specification 1.4
cpu0 at mainbus0: apid 3 (boot processor)
cpu0: apic clock running at 132MHz
mpbios0: bus 0 is type PCI
mpbios0: bus 3 is type PCI
mpbios0: bus 9 is type ISA
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 11, 35 pins
ioapic0: misconfigured as apic 0, remapped to apid 8
bios0: ROM list: 0xc/0x8000 0xc8000/0x4000! 0xe8000/0x6000
0xee000/0x2000!
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "ServerWorks CNB20LE Host" rev 0x06
pchb1 at pci0 dev 0 function 1 "ServerWorks CNB20LE Host" rev 0x06
pci1 at pchb1 bus 3
fxp0 at pci1 dev 4 function 0 "Intel 8255x" rev 0x08, i82559: apic 8 int
17 (irq 5), address 00:02:a5:8b:95:32
inphy0 at fxp0 phy 1: i82555 10/100 PHY, rev. 4
fxp1 at pci1 dev 5 function 0 "Intel 8255x" rev 0x08, i82559: apic 8 int
24 (irq 7), address 00:02:a5:8b:95:31
inphy1 at fxp1 phy 1: i82555 10/100 PHY, rev. 4
ppb0 at pci1 dev 6 function 0 "DEC 21152 PCI-PCI" rev 0x03
pci2 at ppb0 bus 4
fxp2 at pci2 dev 4 function 0 "Intel 8255x" rev 0x05, i82558: apic 8 int
23 (irq 11), address 00:03:47:42:3a:c5
inphy2 at fxp2 phy 1: i82555 10/100 PHY, rev. 0
fxp3 at pci2 dev 5 function 0 "Intel 8255x" rev 0x05, i82558: apic 8 int
22 (irq 10), address 00:03:47:42:3a:c6
inphy3 at fxp3 phy 1: i82555 10/100 PHY, rev. 0
cac0 at pci0 dev 1 function 0 "Symbios Logic 53c1510" rev 0x02: apic 8
int 19 (irq 3), Integrated Array
scsibus0 at cac0: 1 targets
sd0 at scsibus0 targ 0 lun 0: SCSI2 0/direct
fixed
sd0: 17359MB, 512 bytes/sec, 35553120 sec total
vga1 at pci0 dev 3 function 0 "ATI Mach64" rev 0x7a
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
"Compaq Netelligent ASMC" rev 0x00 at pci0 dev 4 function 0 not
configured
ppb1 at pci0 dev 5 function 0 "DEC 21152 PCI-PCI" rev 0x03
pci3 at ppb1 bus 1
fxp4 at pci3 dev 4 function 0 "Intel 8255x" rev 0x05, i82558: apic 8 int
21 (irq 10), address 00:d0:b7:82:dd:ae
inphy4 at fxp4 phy 1: i82555 10/100 PHY, rev. 0
fxp5 at pci3 dev 5 function 0 "Intel 8255x" rev 0x05, i82558: apic 8 int
20 (irq 11), address 00:d0:b7:82:dd:af
inphy5 at fxp5 phy 1: i82555 10/100 PHY, rev. 0
piixpm0 at pci0 dev 15 function 0 "ServerWorks OSB4" rev 0x51: SMBus
disabled
pciide0 at pci0 dev 15 function 1 "ServerWorks OSB4 IDE" rev 0x00: DMA
atapiscsi0 at pciide0 channel 1 drive 0
scsibus1 at atapiscsi0: 2 targets
cd0 at scsibus1 targ 0 lun 0: ATAPI 5/cdrom
dhcrelay barfing on startup via rc
Attempting to enable dhcrelay to run via rc.conf.local is barfing. Specifically running the daemon interactively seems happy: $ sudo dhcrelay -i fxp3 192.168.100.6 $ $ ps -ax | grep dhcrelay 31341 ?? Is 0:00.00 dhcrelay -i fxp3 192.168.100.6 $ Subsequently, my DHCP server now responds to DHCP request from this segment on fxp3. Life is good. However attempting to configure for start upon reboot fails: $ cat /etc/rc.conf.local | grep dhcrelay dhcrelay_flags="-i fxp3 192.168.100.6" *INSERT REBOOT HERE* $ ps -ax | grep dhcrelay $ $ more /var/log/daemon | grep dhcrelay Jan 4 16:11:49 fw01 dhcrelay: fxp3: host unknown Jan 4 16:11:49 fw01 dhcrelay: no interface given Jan 4 16:11:49 fw01 dhcrelay: exiting. Jan 4 16:11:57 fw01 dhcrelay: Can't find free bpf: Permission denied Jan 4 16:11:57 fw01 dhcrelay: exiting. Jan 4 16:12:12 fw01 dhcrelay: Can't find free bpf: Permission denied Jan 4 16:12:12 fw01 dhcrelay: exiting. Jan 4 16:14:25 fw01 dhcrelay: Can't find free bpf: Permission denied Jan 4 16:14:25 fw01 dhcrelay: exiting. Jan 4 17:00:54 fw01 dhcrelay: Can't find free bpf: Permission denied Jan 4 17:00:54 fw01 dhcrelay: exiting. Jan 4 17:12:58 fw01 dhcrelay: connect: Address already in use Jan 4 17:12:58 fw01 dhcrelay: exiting. $ Haven't found much online about others dealing with this. Man pages for dhcrelay, rc.conf.local, etc... haven't yielded much either. Any pointers and or RTFM suggestions appreciated. -sc
dhcrelay problem
Hi, I am trying to figure out if there is anything special one has to do on a openBSD box to allow DHCP relay. I am trying to get an IP address from a DHCP server which is located on another network. The network is a fully bridged based network. The remote firewall is OpenBSD pf. Here is a quick network diagram in client --> [Switch]>[10.108.192 bsd, dhcprelay enabled] ->network>dhcpserver 10.110.218.34 Please let me know if there are any special configurations required on the openBSD boxes. I have tried using dhcprelay (part of the ISC dhcp package), but haven't had any success.. used:dhcrelay -i em1 10.110.218.34 Dec 05 17:32:28.096531 rule 94/(match) pass out on em0: 10.108.192.4 > 10.110.218.34: icmp: 10.108.192.4 udp port 67 unreachable Dec 05 17:32:36.991689 rule 94/(match) pass in on em0: 10.110.218.34.67 > 10.108.192.4.67: (reply) xid:0x415c814d secs:59 Y:10.108.218.128 S:10.108.192.1 [|bootp] (DF) As you can see bsd gets the ip address from remote network but some how Openbsd doesn't broadcast this or client have some issues. Please help me Thanks Farhan _ Net yourself a bargain. Find great deals on eBay. http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Frover%2Eebay%2Ecom%2Frover%2F 1%2F705%2D10129%2D5668%2D323%2F4%3Fid%3D10&_t=763807330&_r=hotmailTAGLINES&_m =EXT
dhcrelay question
I'm running OpenBSD as an IP less bridge between a DMZ and a protected
internet. The protection comes from using a set of pf rules on the
exterior interface of the bridge. My pf rules block all traffic on UDP/
67 and UDP/68 from traversing the bridge so I currently run two DHCP
servers, one in the DMZ and one on the protected network. I'd like to
run dhcrelay on the bridge and add some sort of token to dhcp requests
coming from the DMZ (From new and test servers) so I a can
differentiate them from dhcp requests on the protected network.
Basically I'd like to hand out addresses from one IP range on the DMZ
and from another IP range on the protected network.
I'd imagine that to start I'd want to configure dhcrelay to startup
similar to:
# dhcrelay -i ${dmz_if} ${prot_dhcp_server}
but how do I set this up to differentiate the requests from one another.
Has anyone done this before?
-- Chris
Chris Hilton tildeChris -- http://myblog.vindaloo.com
email -- chris/at/vindaloo/
dot/com
.~
~
.--.~
~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.--.~~.
"I'm on the outside looking inside, What do
I see?
Much confusion, disillution, all
around me."
-- Ian McDonald / Peter
Sinfield
Re: dhcrelay on carp interface (above vlan)
Am 14.03.2008 um 08:13 schrieb Marc Balmer: Falk Brockerhoff - smartTERRA GmbH wrote: I think a good solutions is to look if the given interface is a carp interface and to figure out the carpdev interface. Then this can be used to listen on. But my programming skills are really poor, else I would provide a patch... you can provide the interface name on the command line using -i: e.g. carp0 carpdev vr0 Yes, I know. But I have to provide a numbered interface. In this case the carp interface. This results in have dhcprelay listening on this carp interface, too. But it have to listen on the vlan (in your example the physical interface vr0) interface to catch the dhcp request. That's my problem :-) Regards, Falk Brockerhoff
Re: dhcrelay on carp interface (above vlan)
Hi, I think a good solutions is to look if the given interface is a carp interface and to figure out the carpdev interface. Then this can be used to listen on. But my programming skills are really poor, else I would provide a patch... Regards, Falk
dhcrelay on carp interface (above vlan)
Hi, I run a firewall cluster with several vlans configured on one physical interface. On this vlans I have a carp interface. Same on a second firewall node, so failover is fine. To be able to install or boot servers from the network I set up an PXE boot server. But it's a little bit annoying to configure the switch port's vlan each time I want to use PXE boot. That's why I like to use dhcrelay on the firewall. But, there is a problem: dhcrelay can only be started on a numbered interface - as expected. Here this is the carp-interface. But the dhcp/ bootp requests are send via the vlan interface, as I can see with tcpdump. So dhcrelay won't forward any of these requests. Actualy I can have failover between the firewalls with carp, or dhcrelay without carp and only with vlans, but no redundandcy. What a pity. Is there a way to have both, failover and dhcrelay capabilities? Regards, Falk
Re: More then 1 dhcrelay process on 1 router
Guido Tschakert wrote: Hello folks short: will 2 (or more) dhcrelay work on one router without problems long: I have a router connected to 3 networks: a.b.1.0/24 connected to if1, a.b.2.0/24 connceted to if2, a.b.3.0/24 connected to if3. Lets say I have a dhcpd on a.b.1.1 Is it possible to start the two dhcrelay processes: dhcrelay /usr/sbin/dhcrelay -i if2 a.b.1.1 /usr/sbin/dhcrelay -i if3 a.b.1.1 or will they interfere? If no one knows an answer I will test it next week, as for now I don't have a spare machine with enough network cards ready ;-) thanks guido I have been doing this for over a year and have not had a problem. The only small issue is that you must run them from rc.local because rc.conf.local is only capable of running one dhcrelay.
Re: More then 1 dhcrelay process on 1 router
Guido Tschakert schrieb: > Hello folks > > short: > will 2 (or more) dhcrelay work on one router without problems > > long: > I have a router connected to 3 networks: > a.b.1.0/24 connected to if1, > a.b.2.0/24 connceted to if2, > a.b.3.0/24 connected to if3. > > Lets say I have a dhcpd on a.b.1.1 > > Is it possible to start the two dhcrelay processes: > > dhcrelay > /usr/sbin/dhcrelay -i if2 a.b.1.1 > /usr/sbin/dhcrelay -i if3 a.b.1.1 > > or will they interfere? > > If no one knows an answer I will test it next week, as for now I don't > have a spare machine with enough network cards ready ;-) > > thanks guido > > Ok, If found some hardware to test it: it just worked out of the box. That is why I love OpenBSD: It just work! guido
More then 1 dhcrelay process on 1 router
Hello folks short: will 2 (or more) dhcrelay work on one router without problems long: I have a router connected to 3 networks: a.b.1.0/24 connected to if1, a.b.2.0/24 connceted to if2, a.b.3.0/24 connected to if3. Lets say I have a dhcpd on a.b.1.1 Is it possible to start the two dhcrelay processes: dhcrelay /usr/sbin/dhcrelay -i if2 a.b.1.1 /usr/sbin/dhcrelay -i if3 a.b.1.1 or will they interfere? If no one knows an answer I will test it next week, as for now I don't have a spare machine with enough network cards ready ;-) thanks guido
