Getting EHOSTUNREACH -- No route to host error while sending a UDP packet on IPv6 socket.
Tuks
Can someone please help me removing EHOSTUNREACH -- No route to host
error?
I am stuck very badly and not able understand why is it happening.
My IPv4-v6 dual stack is up properly. I can see a link local address
if I give ifShow command.
I am trying to connect to an IPv6 server at some other location. This
connectivity is through 6to4 tunnel configured on an Extereme
Switch.
I can see that router advertisement packets are coming from the
Extreme switch but my client is not updating its routing table with
that router's IP address. I checked all the #define INCLUDEs to be
enabled in bsp specific config.h for this to work. All the changes
seem to fine to me.
Can someone please help me out in understanding why this might not be
working?
Appreciate any kind of help!!!
Bill
Unfortunately, in you have not told us certain key information:
- What version of VxWorks do you have?
- What BSP are you using?
- What hardware (CPU, network controller) are you using?
We can not guess this information, and it is actually rather crucial
to diagnosing the problem. You should always include this info when
you ask a question, even if you don't think it matters.
IPv6 routing advertisements are multicasts. This means that your
network driver must support reception of multicast ethernet frames in
order for IPv6 to work right. The driver for whatever network device
you're using is probably broken and not programming the multicast
filter correctly.
If the driver came with VxWorks and you have a support contract, check
to see if there is a fix available from Wind River. If not, open a
support call.
If you're using a 3rd party BSP that came with its own driver, contact
the BSP vendor for a fix.
If you wrote the driver yourself, fix it so it handles multicasts
correctly.
-Bill
Tuks
Hello Bill,
Thank you for responding.
Please find the answers to the queries that you asked.
- What version of VxWorks do you have?
VxWorks version 5.5.1, KERNEL: WIND version 2.6
- What BSP are you using?
Broadcom BSP.
- What hardware (CPU, network controller) are you using?
CPU: BCM1103 A5. Network controllers and drivers are all provided by
Bradcom.
Actually, in the older relase of my our products, this functionality
is working fine. The hardware and OS is same in those old releases and
this current release.
Even, I just made the changes in my current product which are related
to enable the IPv6 stack and checked the routing table. But still
could not succeed.
I am wondering why routing table is getting updated in old release and
not in the new one.
Am I missing any changes in enabling the IPv6 stack up?
I you want, I 'll tell what changes did I do for enabling the dual
stack up.
-Thanks & Regards,
Tukaram M. Khandekar.
Praveen
I faced similar problem with WS-Print, I solved by setting the socket
opt to avoid EHOSTUNREACH.
Bill
Does Broadcom provide the driver source as well, or just object code?
> Actually, in the older relase of my our products, this functionality
> is working fine. The hardware and OS is same in those old releases and
> this current release.
Then what is different? If the OS, hardware and TCP/IP stack are all
the same, then this should all still be working. What did you change?
(There must be something other than your own application code.)
> Even, I just made the changes in my current product which are related
> to enable the IPv6 stack and checked the routing table. But still
> could not succeed.
>
> I am wondering why routing table is getting updated in old release and
> not in the new one.
> Am I missing any changes in enabling the IPv6 stack up?
>
> I you want, I 'll tell what changes did I do for enabling the dual
> stack up.
You stopped just short of putting the pieces together. Nobody can tell
you what changes are missing withouy knowing what changes you made in
the first place. Just explain what you did.
> -Thanks & Regards,
> Tukaram M. Khandekar.
VxWorks 5.5.1 out of the box only supports IPv4. I must assume you
have purchased an additional product to add IPv6 support. (Wind River
PNE? PCD?)
I still suspect a problem with multicast support. I know you said the
OS and hardware hasn't changed, but something is different now. All I
can suggest is you do some basic debugging to try to narrow down the
problem.
If you have the Wind River IPv6 stack, there should be an
INCLUDE_PING6 component to provide VxWorks with an IPv6-capable ping
utility. I would add this and then see if you can ping any local IPv6
host, and then see if you can ping other hosts on the other side of
the tunnel.
Also, I would use a network sniffer (e.g. Wireshark) to scan the
network traffic arriving at the VxWorks target to make sure any
routing updates you expect are actually arriving at the target.
Lastly, I would try setting the network controller to promiscuous
mode. You should be able to do this via a socket ioctl() with
SIOCSIFFLAGS to set the IFF_PROMISC flag. If things are working
correctly, the socket ioctl() should translate down to a muxIoctl(),
which in turn will call the ioctl() handler in the underlying ethernet
driver. Setting the interface to promiscuous mode is a hack to allow
it to receive all traffic, including multicasts. If my suspicions are
correct, your IPv6 connectivity will work now. In that case, there is
a problem somewhere with how the multicast filter in the network
driver is being updated. You should investigate this rather than
relying on promisc mode.
I don't know if you have the source code for the ethernet driver or
not. If you do, I would add some instrumentation just to make sure
promiscuous mode is being enabled, and/or to confirm whether or not
the multicast filter setup is bring done correctly.
-Bill
Tuks
Hi Bill,
Apologies for the delay in responding as I was busy in searching the
solution for the same problem.
As per your suggestions, I did few things and below are my
observations:
I have written a code which give me the details about the packets
received and/or transmitted from the layer2 to layer 3.
1. If I give a command ping6 "-I bcm0 fe80::204:96ff:fe36:11e9", I can
see on the Ethereal Trace a neighbour solicitation going out from
my phone fe80::204:dff:feeb:c23d (Source Address) to Extreme router
ff02::1:ff36:11e9 (Destination Address). The Extreme router's actual
Link local address is
fe80::204:96ff:fe36:11e9.
But, I do not get any response back for my neighbour solicitation
messages and ultimately ping6 command.
2. Even, I have one more observation. Task tRtSol which is a task
which sends Neighbour Solicitation messages is always in PEND+T state.
Why is it so? can this cause any problem?
-> i
NAME ENTRY TID PRI STATUS PC SP
ERRNO DELAY
---------- ------------ -------- --- ---------- -------- --------
------- -----
tRtSol rtsol_main 81d72bb0 100 PEND+T 805967cc 81d727d8
3d0002 1340
When my system boots up, I can see that only one Router Solicitation
message goes out with the src address as fe80::204:dff:feeb:c23d and
destination address
to ff02::2. I can see the prinfs in on the console showing me that.
But, Router Advertisement message can be seen only on the Ethereal
traces. I can not see any printfs I put in my receive filter.
Can you please throw some light on this?
Praveen
As per my understanding... tNetTask sends neighbour solicitation and
not tRtSol (this is for router solicitation). to communicate, did your
device got link local ipv6 address?