Dear all,

I would like to know if any body of you has already experienced misbehaviour
of 3Com (Ethernet) NICs when experimenting with MIPL, NEPL or simply IPv6...

For the moment, I can tell from three observations:

1/ Some time ago, I had a problem with a simple Nemo implementation based on
MIPL 1.0. The problem was that the CoA expired without being renewed (the
RAs continued to be sent), and thus the BU expired as well and the mobility
support failed.

2/ Last week, I assisted a partner who expirienced problems to setup a NEPL
0.2 platform in this lab with a correct configuration (addresses, radvd,
nemod). The problem as that when nemod was switched on (on a visisted
network), it started quite well but did not at all recognize that it was
conencted to a visited link, totally ignoring the RAs and not configuring a
Stateless Address. Regarding the behaviour and output of nemod, it was as if
the MR was totally isolated, not connected.
However, we are sure that the configuration was correct because after
replacing the 3Com NICs he used, everything worked perfect immediately.

3/ When setting up a NEPL platform with (Nautlilus6) MCoA support, I used a
3Com NIC as second egress interface, besides 2 Intel NICs as first egress
and as ingress interface.
Basic NEPL worked fine, only using the Intel cards. However, when deploying
NEPL+MCoA with the 3Com card, it started well, registered both CoAs with the
HA, but as soon as there was any movement (disconnection from the visited
link, HO to another visisted link) on one of the egress interfaces, nemoed
did not always correctly de-register the old CoA or not correctly register
the new one, letting expire one or both bindings.
Then, each time when trying to stop the deaemon (Ctrl-C in debug level 10),
I realized that it was somehow stuck: It displayed "SIGINT received", but
did not go any further, i.e. did not exit properly. Also, the tunnel(s) set
up by the daemon were not erased, but continued to exist after killing the
(stuck) daemon

We did not have the time to analyse in detail this strange behaviour, but it
might be due to incorrect handling of RAs..
In any case, if somebody has had similar problems or even found a
workaround, I owuld be pleased to hear about that!

Best regards,
Tobias
_______________________________________________
mipl mailing list
[email protected]
http://www.mobile-ipv6.org/cgi-bin/mailman/listinfo/mipl

Reply via email to