Thomas Schäfer <tschaefer@xxxxxxxxxxx> writes: > Am Samstag, 12. Oktober 2013, 13:46:19 schrieben Sie: >> So the questions still are: Do you see those solicitatins going from the >> driver to the IP layer? And do you see any Neighbor Advertisement >> replies from the IP layer? If the respective answers are yes/no, then >> you should look elsewhere to find the problem. Too restrictive >> ip6tables maybe? > > You asked a lot of questions. I attached two files, captured at wwan0 and at > "any". I see no answers to the NS there, so I assume that's the reason this does not work. But after looking at this again I am not as sure about my conclusions anymore. I do note that the NS is forwarded to the IP layer with an all zeroes MAC source address and the netdev unicast MAC destination address, as expected as those are the dummy values the driver put on any packet. These addresses are of course not correct. Neither of them in fact, as we would expect a multicast destination address here. So these packets could fail if there is anything validation those L2 addresses after the driver is finished. I've looked over and over again on ndisc_rcv() and ndisc_recv_ns() and cannot see any reason why it should fail, though. This is way out of my league... Too bad I don't have a working IPv6 enabled SIM at the moment. I fear this requires a bit of debugging to see where these NS end up. > Only one thing surprises me. There are more than one routeradvertisements. > ( in the past at the qmi devices I have seen it only once per connection) That could be because the firmware resends it until it sees a host address (which could depend on ND success), or just because this firmware is different and send it periodically. That seems more failsafe in any case, and cannot harm. Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
