On Fri, Sep 02, 2022 at 07:03:54PM +0200, YASUOKA Masahiko wrote:
> The diff already considers that situation.
You explanation makes sense.
> > I am running regress test with diff right now, we will see if it
> > still works.
Regress passes.
OK bluhm@
> >> Index: sys/net/pf.c
> >>
Hi,
On Fri, 2 Sep 2022 17:40:13 +0200
Alexander Bluhm wrote:
> On Fri, Sep 02, 2022 at 03:04:34PM +0200, YASUOKA Masahiko wrote:
>> The diff is to fix a problem in a complex setup.
>>
>> Normal setup of divert-reply for TCP connection:
>>
>>
On Fri, Sep 02, 2022 at 03:04:34PM +0200, YASUOKA Masahiko wrote:
> Hi,
>
> The diff is to fix a problem in a complex setup.
>
> Normal setup of divert-reply for TCP connection:
>
> client --- relayd --- server
>
> - transparently forward TCP connections
> -
Hi,
The diff is to fix a problem in a complex setup.
Normal setup of divert-reply for TCP connection:
client --- relayd --- server
- transparently forward TCP connections
- divert-reply is configured the outbound connection to the server
- so that the PF state is removed when the PCB is
. No more interface, but gateway
> > > > addresses. It seems that some parts of the documentation were
> > > > missed.
> > > >
> > > > > should the manpage be improved for reply-to and talk about
> > > > > 'destination
> >
ote:
> > > > did i screwup something somewhere in my config and there's a better way
> > > > for that ?
> > >
> > > This was changed in February. No more interface, but gateway
> > > addresses. It seems that some parts of the documentation were
&g
i screwup something somewhere in my config and there's a better way
> > > > for that ?
> > >
> > > This was changed in February. No more interface, but gateway
> > > addresses. It seems that some parts of the documentation were
> > >
a better way
> > > for that ?
> >
> > This was changed in February. No more interface, but gateway
> > addresses. It seems that some parts of the documentation were
> > missed.
> >
> > > should the manpage be improved for reply-to and talk abou
ore interface, but gateway
> addresses. It seems that some parts of the documentation were
> missed.
>
> > should the manpage be improved for reply-to and talk about 'destination
> > address' instead of 'interface' like route-to does ?
>
> Yes.
>
&g
gt; should the manpage be improved for reply-to and talk about 'destination
> address' instead of 'interface' like route-to does ?
Yes.
It looks like most information is in the commit message.
https://marc.info/?l=openbsd-cvs&m=161213948819452&w=2
bluhm
hi,
on a carp setup with two external links (main & backup), i struggled a
bit to accept traffic on the backup interface - after fiddling a bit in
pf.conf and looking at the faq
(https://www.openbsd.org/faq/upgrade69.html) & manpage
(https://man.openbsd.org/pf.conf#reply-to) it was
Hello,
On Mon, Mar 29, 2021 at 11:56:40AM +, Schreilechner, Dominik wrote:
>
>
> > > I think the changes in ip_insertoptions() can be dropped completely,
> > > because the if-statement uses ip-ip_hl, which might not be initialized.
> >
> > yes, you are right, I think we should rather go
> > I think the changes in ip_insertoptions() can be dropped completely,
> > because the if-statement uses ip-ip_hl, which might not be initialized.
>
> yes, you are right, I think we should rather go for this tweak:
>
> 8<---8<---8<--8<
I think so too. Alternative way would be to pass send flags via m_pkthdr
> > in mbuf, however there is no space. We would have to add a new member
> > to m_pkthdr. I see such change as too intrusive (given we address a true
> > corner case).
>
> I
Hello,
> > @@ -790,6 +795,7 @@ ip_insertoptions(struct mbuf *m, struct mbuf *opt, int
> > *phlen)
> > memcpy(ip + 1, p->ipopt_list, optlen);
> > *phlen = sizeof(struct ip) + optlen;
> > ip->ip_len = htons(ntohs(ip->ip_len) + optlen);
> > + ip->ip_hl += (optlen >> 2
would have to add a new member
> to m_pkthdr. I see such change as too intrusive (given we address a true
> corner case).
I just wanted to reply, but you beat me to it :)
I think the changes in ip_insertoptions() can be dropped completely,
because the if-statement uses ip-ip_hl,
On Fri, Mar 26, 2021 at 11:00:22AM +, Schreilechner, Dominik wrote:
> --- a/sys/netinet/ip_output.c
> +++ b/sys/netinet/ip_output.c
> @@ -765,6 +765,11 @@ ip_insertoptions(struct mbuf *m, struct mbuf *opt, int
> *phlen)
> optlen = opt->m_len - sizeof(p->ipopt_dst);
> if (optlen
Hello,
>
> You missed the initialization of ipsendraw_mq. Otherwise, ICMP with and
> without IP options work for me with the diff.
>
> I don't know how this is usually handled here and it is probably a bit
> nit-picky, but I introduced a new function to remove the duplicate code
> in ip_send_dis
> -Original Message-
> From: Alexandr Nedvedicky
> Sent: Donnerstag, 25. März 2021 17:36
> To: Schreilechner, Dominik (RC-AT DI FA DH-GRAZ ICO)
>
> Cc: tech@openbsd.org
> Subject: Re: [External] : [ICMP] IP options lead to malformed reply
>
> Hello,
>
>
Hello,
> > 1) ip_insertoptions() does not update length of IP header (ip_hl)
> >
> > 2) ip_hl is being overridden anyway later in ip_output() called
> > by ip_send_dispatch() to send ICMP error packet out. Looks
> > like ip_send_dispatch() should use IP_RAWOUTPUT fla
> -Original Message-
> From: Alexandr Nedvedicky
> Sent: Mittwoch, 24. März 2021 23:09
> To: Schreilechner, Dominik (RC-AT DI FA DH-GRAZ ICO)
>
> Cc: tech@openbsd.org
> Subject: Re: [External] : [ICMP] IP options lead to malformed reply
>
> Hello,
>
>
&g
Hello,
> We really need to fix ip_send() such the output task will handle IP options
> properly.
took a look at bug reported by Dominik earlier today. Looks like
there are two issues:
1) ip_insertoptions() does not update length of IP header (ip_hl)
2) ip_hl is being o
le IP options
properly.
thanks and
regards
sashan
On Wed, Mar 24, 2021 at 01:36:20PM +, Schreilechner, Dominik wrote:
> Hi,
>
> When sending an ICMP request with IP options to an OpenBSD Box, the
> ICMP payload of the reply is malformed. In the reply the length field
> of the I
Hi,
When sending an ICMP request with IP options to an OpenBSD Box, the
ICMP payload of the reply is malformed. In the reply the length field
of the IP header is 20, even though the reply contains the IP options.
Meaning, in this packet the IP options are part of ICMP and not IP.
This was tested
> On 25 Jan 2021, at 10:43, Alexandr Nedvedicky
> wrote:
>
> hello,
>
> On Fri, Jan 22, 2021 at 05:32:47PM +1000, David Gwynne wrote:
>> I tried this diff, and it broke the ability to use dynamic addresses.
>> ie, the following rules should work:
>>
>> pass in on gre52 inet proto icmp route
hello,
On Fri, Jan 22, 2021 at 05:32:47PM +1000, David Gwynne wrote:
> I tried this diff, and it broke the ability to use dynamic addresses.
> ie, the following rules should work:
>
> pass in on gre52 inet proto icmp route-to (gre49:peer)
> pass in on vmx0 inet proto icmp route-to (gre:peer)
, Jan 12, 2021 at 08:45:22PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> proposed diff follows stuff discussed here [1] (pf route-to issues). I think
> we've reached a consensus to change route-to/reply-to such the only supported
> option will be next-hop (and list and ta
Hello,
On Fri, Jan 15, 2021 at 06:26:48PM +0100, Alexander Bluhm wrote:
> On Tue, Jan 12, 2021 at 08:45:22PM +0100, Alexandr Nedvedicky wrote:
> > I think bluhm@ and dlg@ have committed part of that change already.
>
> I have only commited a refactoring change. Next step in kernel
> would be to
On Tue, Jan 12, 2021 at 08:45:22PM +0100, Alexandr Nedvedicky wrote:
> I think bluhm@ and dlg@ have committed part of that change already.
I have only commited a refactoring change. Next step in kernel
would be to remove the check in pf_find_state() and see what happens.
I was waiting for dlg@ t
Hello,
proposed diff follows stuff discussed here [1] (pf route-to issues). I think
we've reached a consensus to change route-to/reply-to such the only supported
option will be next-hop (and list and table of next-hop addresses).
I think bluhm@ and dlg@ have committed part of that c
Hi,
I'd like to run relayd as _relayd group always so that we can use
"group _relayd" in a pf rule. This makes it possible to write a pf
rule easily which is to match only connections from relayd(8).
Also as for relayd.conf(5), I'd like to mention that "dive
On Mon, Oct 26, 2015 at 07:08:19PM +0100, Martin Pieuchot wrote:
> This rewrites the code to send an ARP reply to no use ``myaddr''. The
> goal is to get rid of the per-ifp address list iterations.
>
> Instead do two route lookups.
>
> ok?
Should the "repl
This rewrites the code to send an ARP reply to no use ``myaddr''. The
goal is to get rid of the per-ifp address list iterations.
Instead do two route lookups.
ok?
Index: netinet/if_ether.c
===
RCS file: /cvs/src/s
I felt hacking custom scripts to add the In-Reply-To header in a reply
is a bad solution if there's no reason we can't just make mail do it
automagically. So, here comes the diff.
There are a few additional changes here:
- Names starting with underscores are reserved, so I gave
ded, to overwrite the old
> one.
>
> Destination Gateway Flags RefsUse Mtu Prio Iface
> default 172.16.94.113UG 2482 -32 tun0
> default 217.0.116.247UGS 20203 -48 pppoe0
>
>
> For incoming connections
.
Destination Gateway Flags RefsUse Mtu Prio Iface
default 172.16.94.113UG 2482 -32 tun0
default 217.0.116.247UGS 20203 -48 pppoe0
For incoming connections on pppoe0 I am using reply-to, so the packets
go back out where they
some sites enforce a minimum reply length, so when you send them
8 bytes of user data, they reply with your 8 bytes and zero padding
to the minumum reply length. our ping6 code then fails to compare
data against its internal buffer because it doesn&#
Hi all,
I'm working on a patch to make the rules route-to and reply-to to be
synced between two firewalls in HA schema, pfsync breaks the route-to
state when the state is imported.
This patch will break the pfsync protocol, because the addition of
char rt_ifname[IFNAMSIZ] in pfsync_state s
Hello,
This is Harry Barnes of the 1st Battalion Scots Guard, but redeployed to Iraq,
and presently stationed in Mushirij South West of Basra. I will like to share
some very vital information that would bring some good financial returns to us
in just a few weeks or days depending on how fast we
Bonjour,
Je suis en congis du lundi 22 juin au lundi 6 juillet inclus. Voici la liste
des personnes ` contacter durant mon absence : Laurent Cantone 04 97 12 87 96
et Antoine Louis 01 58 96 62 73.
Merci de systimatiquement utiliser la mailing liste suivante :
reseau.r...@list.hebex.orangeportai
I've just been trying to update a socks server to support IPv6 and found
that nc wasn't consuming all of the socks connect reply. I think that this
patch fixes this.
Index: socks.c
===
RCS file: /cvs/src/usr.bin/nc
41 matches
Mail list logo
