search

radvd-project / radvd

radvd | Official repository: https://github.com/radvd-project/radvd
https://radvd.litech.org/
Other
203 stars 106 forks source link

Replace ARPHRD_IEEE802154 to ARPHRD_6LOWPAN #50

Closed alexaring closed 8 years ago

alexaring commented 8 years ago

Hi,

in the early days of 6lowpan support, there was 802.15.4 6LoWPAN only. It is still in an experimental state, but was completely unusable in these days. We changed now the ARPHRD from ARPHRD_IEEE802154 to ARPHRD_6LOWPAN. Because it was in a very poor state when it was ARPHRD_IEEE802154, I am fine when it will be replaced by ARPHRD_6LOWPAN. I highly not recommend kernel versions which has still ARPHRD_IEEE802154 for the 802.15.4 6LoWPAN interface.

Nevertheless I am also fine to make some backwards compability:

case ARPHRD_IEEE802154: case ARPHRD_6LOWPAN: /* do stuff */

Also please add:

ifndef ARPHRD_6LOWPAN

define ARPHRD_6LOWPAN 825 /* IPv6 over LoWPAN */

endif

to make it available if somebody use old kernel header versions. The ARPHRD_6LOWPAN will be used by all 6LoWPAN interfaces now. Currently we have support for 802.15.4 and BTLE 6LoWPAN. Both use currently an EUI64 address as link address. (We still need support for 802.15.4 short address, but this is another issue).

Also please note ARPHRD_IEEE802154 is here wrong. This type is still used by the wpan interfaces which don't has IPv6 functionality (MTU < 1280).

reubenhwk commented 8 years ago

Please submit a patch.

On Mon, Nov 30, 2015 at 4:19 AM, Alexander Aring notifications@github.com wrote:

Hi,

in the early days of 6lowpan support, there was 802.15.4 6LoWPAN only. It is still in an experimental state, but was completely unusable in these days. We changed now the ARPHRD from ARPHRD_IEEE802154 to ARPHRD_6LOWPAN. Because it was in a very poor state when it was ARPHRD_IEEE802154, I am fine when it will be replaced by ARPHRD_6LOWPAN. I highly not recommend kernel versions which has still ARPHRD_IEEE802154 for the 802.15.4 6LoWPAN interface.

Nevertheless I am also fine to make some backwards compability:

case ARPHRD_IEEE802154: case ARPHRD_6LOWPAN: /* do stuff */

Also please add:

ifndef ARPHRD_6LOWPAN

define ARPHRD_6LOWPAN 825 /* IPv6 over LoWPAN */

endif

to make it available if somebody use old kernel header versions. The ARPHRD_6LOWPAN will be used by all 6LoWPAN interfaces now. Currently we have support for 802.15.4 and BTLE 6LoWPAN. Both use currently an EUI64 address as link address. (We still need support for 802.15.4 short address, but this is another issue).

Also please note ARPHRD_IEEE802154 is here wrong. This type is still used by the wpan interfaces which don't has IPv6 functionality (MTU < 1280).

— Reply to this email directly or view it on GitHub https://github.com/reubenhwk/radvd/issues/50.

smlng commented 8 years ago

Hi all,

I implemented the changes proposed by @alexaring above, but it I feel I have redone work already done. At least I found some mail archives with multiple patches for RADVD 6lowpan support, why are these changes not reflected here, at least in some devel or 6lowpan branch?

smlng commented 8 years ago

Hi again,

I will make a pull request anyway. However, I saw another patch regarding 6lowpan compression context options, would be nice to have that too. I currently use radvd for a 6L border router setup using a RasPi with openlabs transceiver and sensor nodes running @RIOT-OS.

alexaring commented 8 years ago

Please, don't use these patches which you seeing around for a real 6CO support. I have changed the API for the last stateful compression mainline patches, I will send them somehow again and will try to cc you.

Nevertheless, we/I came to decision that running radvd is wrong for 6LoWPAN networks. What we need is a RPL implementation like @mcr unstrung repository which handles RA-messages then. Nevertheless you could radvd for that and is has support for 6CO yet, but remember we/I think to still working on radvd for RFC6775 is wrong.

reubenhwk commented 8 years ago

Will do. Thanks for the heads up.

Sent from my iPhone

On Feb 14, 2016, at 11:59 AM, Alexander Aring notifications@github.com wrote:

Please, don't use these patches which you seeing around for a real 6CO support. I have changed the API for the last stateful compression mainline patches, I will send them somehow again and will try to cc you.

Nevertheless, we/I came to decision that running radvd is wrong for 6LoWPAN networks. What we need is a RPL implementation like @mcr unstrung repository which handles RA-messages then. Nevertheless you could radvd for that and is has support for 6CO yet, but remember we/I think to still working on radvd for RFC6775 is wrong.

— Reply to this email directly or view it on GitHub.

smlng commented 8 years ago

I do see your point to opt for a full fledged router implementation for 6LoWPAN networks including RPL support. However, I just wanted to setup a rather small sensor network with a Raspberry Pi as 6LR, maybe 6LBR later on. Problem was without the Pi doing RAs I was unable to connect it with sensor nodes running RIOT using non-link local addresses, i.e., ULAs for my isolated test setup. I currently don't need RPL as my nodes are fairly close together and a star topology with the Pi in the center suffices for now - so radvd was a simple (maybe not most elegant) solution for me.

But I have to admit, in the end its just a test setup I and I needed it to run somehow to meet my current requirements. Maybe, if RPL comes into play in the future I have to think about replacing radvd ... but for now I'm good :) Anyway, thank you for pointing me at unstrung - I have a look at that too.

alexaring commented 8 years ago

fixed in 81745920a0b27696aab2e78cecdd807d988cbaee