On Tue, Oct 25, 2011 at 02:28:06PM +0200, René Hummen wrote:
> On 20.10.2011, at 14:15, Diego Biurrun wrote:
> > On Wed, Oct 19, 2011 at 01:17:30PM +0000, René Hummen wrote:
> >
> >> --- Makefile.am 2011-10-17 18:14:10 +0000
> >> +++ Makefile.am 2011-10-19 13:13:48 +0000
> >> @@ -253,7 +256,7 @@
> >>
> >> -test_check_firewall_LDFLAGS = -ldl
> >> +test_check_firewall_LDFLAGS = -ldl -z muldefs
> >
> > We have solved this differently elsewhere by #including the .c file to
> > unit-test static functions.
>
> This has been discussed previously on the list:
> http://www.freelists.org/post/hipl-dev/Mock-functions-for-hipl-unit-tests
But we currently don't favor that solution. If that needs changing,
it's a topic for a separate merge request and would need to be changed
in all places.
> >> @@ -1526,14 +1565,28 @@
> >>
> >> } else if (esp_info && seq && ack) {
> >> - if (!tuple) {
> >> + if (tuple && tuple->direction == ORIGINAL_DIR) {
> >> + other_dir = &tuple->connection->reply;
> >> + } else if (tuple) {
> >> + other_dir = &tuple->connection->original;
> >> + } else {
> >> HIP_ERROR("Insufficient stored state to process UPDATE\n");
> >> return 0;
> >> }
> >
> > tuple is checked twice.
>
> Yes, but I need to be sure that tuple exists when accessing its
> members in the body of the else if.
So? That does not imply you need to check "tuple" twice, just nest the
ifs, witness:
if (tuple) {
if (tuple->direction == ORIGINAL_DIR) {
other_dir = &tuple->connection->reply;
} else {
other_dir = &tuple->connection->original;
} else {
HIP_ERROR("Insufficient stored state to process UPDATE\n");
return 0;
}
> >> - if (!hip_fw_verify_packet(common, tuple)) {
> >> + if (!hipfw_midauth_verify_challenge(ctx, other_dir->midauth_nonce)) {
> >> + HIP_ERROR("failed to verify midauth challenge\n");
> >> + return 0;
> >> + }
> >
> > 0 is returned in case of error?
>
> Yes, firewall/conntrack.c does not use the same semantics for return
> values compared to the rest of the code.
Then fix conntrack.c and don't make the code consistently inconsistent,
cf. the boyscout rule.
> >> @@ -1543,14 +1596,29 @@
> >> } else if (ack) {
> >> - if (!tuple) {
> >> + if (tuple && tuple->direction == ORIGINAL_DIR) {
> >> + other_dir = &tuple->connection->reply;
> >> + } else if (tuple) {
> >> + other_dir = &tuple->connection->original;
> >> + } else {
> >> HIP_ERROR("Insufficient stored state to process UPDATE\n");
> >> return 0;
> >> }
> >
> > another redundant check
> >
> > Oh, this code seems to be completely duplicated.
>
> Yes, but I didn't see the need for a new function as this code is
> specific for updates and only used twice.
There is no such thing as "only" used twice, code duplication
is code duplication is code duplication :)
> >> --- firewall/firewall.c 2011-08-16 07:49:25 +0000
> >> +++ firewall/firewall.c 2011-10-19 13:13:48 +0000
> >> @@ -76,12 +76,13 @@
> >> #include "lib/core/prefix.h"
> >> #include "lib/core/util.h"
> >> #include "hipd/hipd.h"
> >> -#include "config.h"
> >> #include "cache.h"
> >> #include "common_types.h"
> >> +#include "config.h"
> >> #include "conntrack.h"
> >> #include "esp_prot_api.h"
> >> #include "esp_prot_conntrack.h"
> >> +#include "firewall.h"
> >> #include "firewall_control.h"
> >> #include "firewall_defines.h"
> >> #include "helpers.h"
> >> @@ -90,9 +91,9 @@
> >> #include "pisa.h"
> >> #include "port_bindings.h"
> >> #include "reinject.h"
> >> +#include "rewrite.h"
> >> #include "rule_management.h"
> >> #include "user_ipsec_api.h"
> >> -#include "firewall.h"
> >
> > The ordering is actually done on purpose. config.h is not in the same
> > directory, same as the other #includes with directory prefixes and
> > firewall.h directly "belongs" to firewall.c, so it made sense at the
> > time to put it last and list all dependencies before. I have this
> > feeling in the back of my head that the latter solved some real issue.
>
> 'make alltests' runs successfully. So, what exactly is your suggestion?
My suggestion is not to change the #include ordering.
> >> @@ -74,6 +81,8 @@
> >> int modified;
> >> };
> >>
> >> +#include "midauth.h"
> >
> > Why the peculiar placement of this #include?
>
> There is a cyclic redundancy between firewall/midauth.h (requires
> definition of struct hip_fw_context) and firewall/firewall_defines.h
> (requires definition of MIDAUTH_DEFAULT_NONCE_LENGTH). This helps
> mitigating the problem.
So fix the cyclic redundancy, don't add more workarounds.
Doh, that must have been a brainfart from my side.
> >> + if (!found) {
> >> + HIP_ERROR("CHALLENGE_RESPONSE found, but no matching nonce\n");
> >> + return ignore_missing_challenge_response ? 1 : 0;
> >> + }
> >> +
> >> + return found ? 1 : 0;
> >
> > You just checked found, no need to do it again.
>
> I guess that this has been done to ensure correct type conversion from
> bool to int.
Read the code again, it's nonsense, "found" is initialized once and
never set again.
On Tue, Oct 25, 2011 at 02:28:06PM +0200, René Hummen wrote: firewall_ LDFLAGS = -ldl firewall_ LDFLAGS = -ldl -z muldefs www.freelists. org/post/ hipl-dev/ Mock-functions- for-hipl- unit-tests
> On 20.10.2011, at 14:15, Diego Biurrun wrote:
> > On Wed, Oct 19, 2011 at 01:17:30PM +0000, René Hummen wrote:
> >
> >> --- Makefile.am 2011-10-17 18:14:10 +0000
> >> +++ Makefile.am 2011-10-19 13:13:48 +0000
> >> @@ -253,7 +256,7 @@
> >>
> >> -test_check_
> >> +test_check_
> >
> > We have solved this differently elsewhere by #including the .c file to
> > unit-test static functions.
>
> This has been discussed previously on the list:
> http://
But we currently don't favor that solution. If that needs changing,
it's a topic for a separate merge request and would need to be changed
in all places.
> >> @@ -1526,14 +1565,28 @@ >connection- >reply; >connection- >original; "Insufficient stored state to process UPDATE\n");
> >>
> >> } else if (esp_info && seq && ack) {
> >> - if (!tuple) {
> >> + if (tuple && tuple->direction == ORIGINAL_DIR) {
> >> + other_dir = &tuple-
> >> + } else if (tuple) {
> >> + other_dir = &tuple-
> >> + } else {
> >> HIP_ERROR(
> >> return 0;
> >> }
> >
> > tuple is checked twice.
>
> Yes, but I need to be sure that tuple exists when accessing its
> members in the body of the else if.
So? That does not imply you need to check "tuple" twice, just nest the
ifs, witness:
if (tuple) { >connection- >reply; >connection- >original; ERROR(" Insufficient stored state to process UPDATE\n");
if (tuple->direction == ORIGINAL_DIR) {
other_dir = &tuple-
} else {
other_dir = &tuple-
} else {
HIP_
return 0;
}
> >> - if (!hip_fw_ verify_ packet( common, tuple)) { midauth_ verify_ challenge( ctx, other_dir- >midauth_ nonce)) { conntrack. c does not use the same semantics for return
> >> + if (!hipfw_
> >> + HIP_ERROR("failed to verify midauth challenge\n");
> >> + return 0;
> >> + }
> >
> > 0 is returned in case of error?
>
> Yes, firewall/
> values compared to the rest of the code.
Then fix conntrack.c and don't make the code consistently inconsistent,
cf. the boyscout rule.
> >> @@ -1543,14 +1596,29 @@ >connection- >reply; >connection- >original; "Insufficient stored state to process UPDATE\n");
> >> } else if (ack) {
> >> - if (!tuple) {
> >> + if (tuple && tuple->direction == ORIGINAL_DIR) {
> >> + other_dir = &tuple-
> >> + } else if (tuple) {
> >> + other_dir = &tuple-
> >> + } else {
> >> HIP_ERROR(
> >> return 0;
> >> }
> >
> > another redundant check
> >
> > Oh, this code seems to be completely duplicated.
>
> Yes, but I didn't see the need for a new function as this code is
> specific for updates and only used twice.
There is no such thing as "only" used twice, code duplication
is code duplication is code duplication :)
> >> --- firewall/firewall.c 2011-08-16 07:49:25 +0000 conntrack. h" control. h" defines. h"
> >> +++ firewall/firewall.c 2011-10-19 13:13:48 +0000
> >> @@ -76,12 +76,13 @@
> >> #include "lib/core/prefix.h"
> >> #include "lib/core/util.h"
> >> #include "hipd/hipd.h"
> >> -#include "config.h"
> >> #include "cache.h"
> >> #include "common_types.h"
> >> +#include "config.h"
> >> #include "conntrack.h"
> >> #include "esp_prot_api.h"
> >> #include "esp_prot_
> >> +#include "firewall.h"
> >> #include "firewall_
> >> #include "firewall_
> >> #include "helpers.h"
> >> @@ -90,9 +91,9 @@
> >> #include "pisa.h"
> >> #include "port_bindings.h"
> >> #include "reinject.h"
> >> +#include "rewrite.h"
> >> #include "rule_management.h"
> >> #include "user_ipsec_api.h"
> >> -#include "firewall.h"
> >
> > The ordering is actually done on purpose. config.h is not in the same
> > directory, same as the other #includes with directory prefixes and
> > firewall.h directly "belongs" to firewall.c, so it made sense at the
> > time to put it last and list all dependencies before. I have this
> > feeling in the back of my head that the latter solved some real issue.
>
> 'make alltests' runs successfully. So, what exactly is your suggestion?
My suggestion is not to change the #include ordering.
> >> @@ -74,6 +81,8 @@ firewall_ defines. h DEFAULT_ NONCE_LENGTH) . This helps
> >> int modified;
> >> };
> >>
> >> +#include "midauth.h"
> >
> > Why the peculiar placement of this #include?
>
> There is a cyclic redundancy between firewall/midauth.h (requires
> definition of struct hip_fw_context) and firewall/
> (requires definition of MIDAUTH_
> mitigating the problem.
So fix the cyclic redundancy, don't add more workarounds.
> >> +int hipfw_midauth_ verify_ challenge( const struct hip_fw_context *const ctx, nonce[MIDAUTH_ DEFAULT_ NONCE_LENGTH] ) bazaar. launchpad. net/~midauth- pisa-devs/ hipl/midauth- firewall/ view/head: /firewall/ midauth. c#L220
> >> + const uint8_t midauth_
> >
> > missing doxy
>
> Hmm...I can see the doxygen here:
> http://
Doh, that must have been a brainfart from my side.
> >> + if (!found) { "CHALLENGE_ RESPONSE found, but no matching nonce\n"); missing_ challenge_ response ? 1 : 0;
> >> + HIP_ERROR(
> >> + return ignore_
> >> + }
> >> +
> >> + return found ? 1 : 0;
> >
> > You just checked found, no need to do it again.
>
> I guess that this has been done to ensure correct type conversion from
> bool to int.
Read the code again, it's nonsense, "found" is initialized once and
never set again.
Diego
P.S.: You should keep launchpad in CC.