struct net_device_ops: Add function pointer to fill device specific ndisc information
Subsystems (2)
I've implemented IPv6 over firewire. Right now I'm facing the problem that the corresponding RFC3146 requires very firewire specific information sent during neighborhood discovery.
There was already a discussion on the linux1394 mailing list (http://sourceforge.net/mailarchive/message.php?msg_id=30342089 and http://sourceforge.net/mailarchive/forum.php?thread_name=50E4A3E5.8080304%40gmail.com&forum_name=linux1394-devel)
During that discussion all participants agreed that it makes no sense to introduce a dependency between the ndisc code and the firewire net driver.
So the most appealing option seems to be to introduce on more callback routine either in struct net_device or struct net_device_ops:
int (*ndo_fill_llao)(void *llao);
Because I'm not so familiar with the structure of the whole network infrastructure in Linux, I need some advice if struct net_device or struct net_device_ops is the right place.
Maybe it's worth to generalize this and do the same for IPv4/ARP because right now the ARP packets are mangled in the firewire net driver.
Nevertheless, I've to admit that right now it seems that only IPv6 over firewire requires such a callback routine.
Regards,
Stephan
Quoted 8 lines · Stephan Gatzka
I've implemented IPv6 over firewire. Right now I'm facing the problem that the corresponding RFC3146 requires very firewire specific information sent during neighborhood discovery.
There was already a discussion on the linux1394 mailing list (http://sourceforge.net/mailarchive/message.php?msg_id=30342089 and http://sourceforge.net/mailarchive/forum.php?thread_name=50E4A3E5.8080304%40gmail.com&forum_name=linux1394-devel)
During that discussion all participants agreed that it makes no sense to introduce a dependency between the ndisc code and the firewire net driver.
So the most appealing option seems to be to introduce on more callback routine either in struct
net_deviceor structnet_device_ops:
Quoted 7 lines
int (*ndo_fill_llao)(void *llao);
Because I'm not so familiar with the structure of the whole network infrastructure in Linux, I need some advice if struct
net_deviceor structnet_device_opsis the right place.Maybe it's worth to generalize this and do the same for IPv4/ARP because right now the ARP packets are mangled in the firewire net driver.
Nevertheless, I've to admit that right now it seems that only IPv6 over firewire requires such a callback routine.
My current position is to change "mac address" to
struct fwnet_hwaddr {
u8 guid[8];
u8 max_rec;
u8 sspd;
u8 fifo[6];
};Benefits:
[ARP and NDISC]
- both can be handled in more natural way. -- You will not need to mangle those packets when sending/receiving.
-- You do not need to inspect ARP/NDISC packet.
By using netevent notification mechanism, you can learn peer parameters.
-- IP layer is not required to change very much.
[Multicast]
-it can be handled in more natural way.
-- MCAP (Multicast Channel Allocation Protocol) needs to
know full IP multicast address.
-- We have IP multicast address => "hardware address"
mapping for each L2 type in IP layer.
-- We expect that IP layer can request net_device to
receive multicast stream for some multicast address via corresponding "hardware address".
-- This means that we need to have "hardware address"
of 128bits (16 octets) or more.
-- By increasing size of dev->dev_addr, we can embedded
full IPv6 address in it.
--yoshfuji
Quoted 9 lines · YOSHIFUJI Hideaki
My current position is to change "mac address" to
struct fwnet_hwaddr { u8 guid[8]; u8 max_rec; u8 sspd; u8 fifo[6]; };
That is something I'm not really convinced of. As Stefan Richter pointed out clearly, the fifo address might be different between IPv4 and IPv6 communication.
Stephan
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
Quoted 12 lines · Stephan Gatzka
Quoted 9 lines · YOSHIFUJI Hideaki
My current position is to change "mac address" to
struct fwnet_hwaddr { u8 guid[8]; u8 max_rec; u8 sspd; u8 fifo[6]; };
Quoted 1 line
That is something I'm not really convinced of. As Stefan Richter pointed out clearly, the fifo address might be different between IPv4 and IPv6 communication.
We could have multiple "net_device"s per single physical interface at the same time, then.
Multicast is a big issue. Because IPv6 is fan of multicast, and it uses link-local multicast as its core infrastructure. Without infrastructure to support it, I'm not going to agree.
And, firewire driver does not seem to support zerocopy (fragmented skb) support. It help performance.
--yoshfuji
Quoted 2 lines
We could have multiple "net_device"s per single physical interface at the same time, then.
Of course, but I would avoid it if it's not necessary. What's the problem with introducing a function pointer in struct net_device or struct net_device_ops?
Quoted 5 lines
Multicast is a big issue. Because IPv6 is fan of multicast, and it uses link-local multicast as its core infrastructure. Without infrastructure to support it, I'm not going to agree.
firewire net supports multicast and we use it very often. My patch to support IPv6 does not change it. In fact, because I can communicate via IPv6 between two firewire nodes, multicast _is_ running. The driver does not do lot's of special things with multicast packets. But multicast packets are recognized because they have to be sent somehow different (GASP).
Quoted 3 lines
And, firewire driver does not seem to support zerocopy (fragmented skb) support. It help performance.
O.k., good point. I will have a look into that. But I suggest to not mix up this issue with the IPv6 over firewire enhancement. That should be a separate patch.
Stephan
Quoted 6 lines · On Jan 21 Stephan Gatzka wrote:
Quoted 2 lines
We could have multiple "net_device"s per single physical interface at the same time, then.
Of course, but I would avoid it if it's not necessary. What's the problem with introducing a function pointer in struct
net_deviceor structnet_device_ops?
Two net_device instances on one 1394 card would be awkward: They would have to share one instance of isochronous reception context (for reception of asynchronous 1394 streams; those are used for broadcasts and multicasts). Such a sharing is surely possible, but if double net_device instantiation can be avoided, then avoid it.
Not to mention the user interface problem of having two netifs, one which only supports IPv4 and another one which only supports IPv6. So far I never had IPv6 configured into a Linux kernel, but I suppose that folks are used to be able to use eth0 etc. for both protocols.
Quoted 11 lines
Quoted 4 lines
Multicast is a big issue. Because IPv6 is fan of multicast, and it uses link-local multicast as its core infrastructure. Without infrastructure to support it, I'm not going to agree.
firewire net supports multicast and we use it very often. My patch to support IPv6 does not change it. In fact, because I can communicate via IPv6 between two firewire nodes, multicast _is_ running. The driver does not do lot's of special things with multicast packets. But multicast packets are recognized because they have to be sent somehow different (GASP).
(At the moment we transport multicasts to the same 1394 channel like broadcasts.
IEEE 1394 supports two addressing modes: IEEE 1212 based memory-mapable addresses of the form bus:node:offset = 10 bits + 6 bits + 48 bits for node-to-node communication, and "channel" = a 6 bit channel number for communication of 1 node to 0...n nodes.
RFC 2734 broadcasts and multicasts use the channel addressing type. Hence max_rec/ sspd/ unicast_FIFO come not into play with broadcasts and multicasts. Broadcasts are sent to a fixed known channel number; multicasts are sent either to the broadcast channel number or to a separate channel number which is negotiated per multicast group using RFC 2734 Multicast Channel Allocation Protocol. For the time being the Linux driver only implements multicasts to the broadcast channel.)
Signature · 10 lines
Stefan Richter -=====-===-= ---= =-=-= http://arcgraph.de/sr/ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412
Quoted 39 lines · Stefan Richter
Quoted 6 lines · On Jan 21 Stephan Gatzka wrote:
Quoted 2 lines
We could have multiple "net_device"s per single physical interface at the same time, then.
Of course, but I would avoid it if it's not necessary. What's the problem with introducing a function pointer in struct
net_deviceor structnet_device_ops?Two
net_deviceinstances on one 1394 card would be awkward: They would have to share one instance of isochronous reception context (for reception of asynchronous 1394 streams; those are used for broadcasts and multicasts). Such a sharing is surely possible, but if doublenet_deviceinstantiation can be avoided, then avoid it.Not to mention the user interface problem of having two netifs, one which only supports IPv4 and another one which only supports IPv6. So far I never had IPv6 configured into a Linux kernel, but I suppose that folks are used to be able to use eth0 etc. for both protocols.
Quoted 11 lines
Quoted 4 lines
Multicast is a big issue. Because IPv6 is fan of multicast, and it uses link-local multicast as its core infrastructure. Without infrastructure to support it, I'm not going to agree.
firewire net supports multicast and we use it very often. My patch to support IPv6 does not change it. In fact, because I can communicate via IPv6 between two firewire nodes, multicast _is_ running. The driver does not do lot's of special things with multicast packets. But multicast packets are recognized because they have to be sent somehow different (GASP).
(At the moment we transport multicasts to the same 1394 channel like broadcasts.
IEEE 1394 supports two addressing modes: IEEE 1212 based memory-mapable addresses of the form bus:node:offset = 10 bits + 6 bits + 48 bits for node-to-node communication, and "channel" = a 6 bit channel number for communication of 1 node to 0...n nodes.
Quoted 8 lines
RFC 2734 broadcasts and multicasts use the channel addressing type. Hence max_rec/ sspd/
unicast_FIFOcome not into play with broadcasts and multicasts. Broadcasts are sent to a fixed known channel number; multicasts are sent either to the broadcast channel number or to a separate channel number which is negotiated per multicast group using RFC 2734 Multicast Channel Allocation Protocol. For the time being the Linux driver only implements multicasts to the broadcast channel.)
Sending multicast without MCAP is okay,
but receiving multicast without MCAP is broken. We have to be able to listen to NS (DAD) on separate channel which is been negotiated over MCAP, for example.
--yoshfuji
Quoted 11 lines
Two
net_deviceinstances on one 1394 card would be awkward: They would have to share one instance of isochronous reception context (for reception of asynchronous 1394 streams; those are used for broadcasts and multicasts). Such a sharing is surely possible, but if doublenet_deviceinstantiation can be avoided, then avoid it.Not to mention the user interface problem of having two netifs, one which only supports IPv4 and another one which only supports IPv6. So far I never had IPv6 configured into a Linux kernel, but I suppose that folks are used to be able to use eth0 etc. for both protocols.
Full ack. And that's the reason why I feel very uncomfortable with a Yoshifujis hardware address extensions by fifo_addr, spd, and max_rec.
This seems possible with a single netdevice for IPv4/6 only if we _always_ use the same fifo address for both IPv4 and IPv6. Do we all agree on that?
Stephan
Quoted 7 lines · Stephan Gatzka
Quoted 7 lines
Two
net_deviceinstances on one 1394 card would be awkward: They would have to share one instance of isochronous reception context (for reception of asynchronous 1394 streams; those are used for broadcasts and multicasts). Such a sharing is surely possible, but if doublenet_deviceinstantiation can be avoided, then avoid it.
Quoted 8 lines
Quoted 4 lines
Not to mention the user interface problem of having two netifs, one which only supports IPv4 and another one which only supports IPv6. So far I never had IPv6 configured into a Linux kernel, but I suppose that folks are used to be able to use eth0 etc. for both protocols.
Full ack. And that's the reason why I feel very uncomfortable with a Yoshifujis hardware address extensions by
fifo_addr, spd, andmax_rec.This seems possible with a single netdevice for IPv4/6 only if we _always_ use the same fifo address for both IPv4 and IPv6. Do we all agree on that?
I do not understand what "that" and "this" mean here.
Do you want to have different FIFO on single net_device? If yes, for what?
--yoshfuji
Quoted 8 lines
Quoted 4 lines
Full ack. And that's the reason why I feel very uncomfortable with a Yoshifujis hardware address extensions by
fifo_addr, spd, andmax_rec.This seems possible with a single netdevice for IPv4/6 only if we _always_ use the same fifo address for both IPv4 and IPv6. Do we all agree on that?
I do not understand what "that" and "this" mean here.
Do you want to have different FIFO on singlenet_device? If yes, for what?
Oh, I'm sorry for being mixed-up. I meant that your proposal for enhancing the hardware address seems to be a feasible solution, if we _never_ want to have distinct fifo addresses for IPv4 and IPv6. This will be just impossible with a single netdevice.
But I have to admit that I have no good use case for different fifo addresses...
So overall, your proposal seems to be a possible solution. Nevertheless, I can't help that I find it a bit awkward to have speed, max_rec and fifo address in the hardware address of the network device. For me, that's just the GUID.
I want to have an ack from Stefan Richter before I'm going to implement your solution.
Regards,
Stephan
Quoted 17 lines · On Jan 21 Stephan Gatzka wrote:
Quoted 8 lines
Quoted 4 lines
Full ack. And that's the reason why I feel very uncomfortable with a Yoshifujis hardware address extensions by
fifo_addr, spd, andmax_rec.This seems possible with a single netdevice for IPv4/6 only if we _always_ use the same fifo address for both IPv4 and IPv6. Do we all agree on that?
I do not understand what "that" and "this" mean here.
Do you want to have different FIFO on singlenet_device? If yes, for what?Oh, I'm sorry for being mixed-up. I meant that your proposal for enhancing the hardware address seems to be a feasible solution, if we _never_ want to have distinct fifo addresses for IPv4 and IPv6. This will be just impossible with a single netdevice.
But I have to admit that I have no good use case for different fifo addresses...
Quoted 7 lines
So overall, your proposal seems to be a possible solution. Nevertheless, I can't help that I find it a bit awkward to have speed,
max_recand fifo address in the hardware address of the network device. For me, that's just the GUID.I want to have an ack from Stefan Richter before I'm going to implement your solution.
Sorry for my delayed response.
I am not a contributor to net/, hence don't have a say over how the networking APIs should evolve.
Any solution is fine with me, as long as net/ does not use any definitions or declarations from <linux/firewire.h>.
Signature · 3 lines
Stefan Richter -=====-===-= ---= ==-== http://arcgraph.de/sr/
Quoted 7 lines
I am not a contributor to
net/, hence don't have a say over how the networking APIs should evolve.Any solution is fine with me, as long as
net/does not use any definitions or declarations from <linux/firewire.h>.
O.k. then I will go for Yoshifujis "extended hwaddress" approch.
I think I will divide all the stuff into two major pieces:
First I will rewrite the existing IPv4 over Firewire driver to use the notification mechanisms and also generate the RFC2734 ARP packets in the arp code.
Then I'll implement the IPv6 stuff based on that IPv4 solution.
Regards and many thanks for the discussion especially to Yoshifuji.
Stephan
Quoted 5 lines
Then I'll implement the IPv6 stuff based on that IPv4 solution.
Regards and many thanks for the discussion especially to Yoshifuji.
One last question: shall I use net or net-next?
Stephan
Quoted 7 lines · Stephan Gatzka
Quoted 5 lines
Then I'll implement the IPv6 stuff based on that IPv4 solution.
Regards and many thanks for the discussion especially to Yoshifuji.
One last question: shall I use net or net-next?
net-next, please.
--yoshfuji
Quoted 6 lines · Stephan Gatzka
Quoted 5 lines
I am not a contributor to
net/, hence don't have a say over how the networking APIs should evolve.Any solution is fine with me, as long as
net/does not use any definitions or declarations from <linux/firewire.h>.
Quoted 7 lines
O.k. then I will go for Yoshifujis "extended hwaddress" approch.
I think I will divide all the stuff into two major pieces:
First I will rewrite the existing IPv4 over Firewire driver to use the notification mechanisms and also generate the RFC2734 ARP packets in the arp code.
Then I'll implement the IPv6 stuff based on that IPv4 solution.
I even think that we do not need to have event notification if we can just use max_rec, sspd and fifo embedded in the destination "MAC address" in the sending packet.
--yosshfuji
Quoted 12 lines · On Jan 28 YOSHIFUJI Hideaki wrote:
Quoted 10 lines · Stephan Gatzka
Quoted 5 lines
I am not a contributor to
net/, hence don't have a say over how the networking APIs should evolve.Any solution is fine with me, as long as
net/does not use any definitions or declarations from <linux/firewire.h>.O.k. then I will go for Yoshifujis "extended hwaddress" approch.
I think I will divide all the stuff into two major pieces:
Quoted 7 lines
Quoted 3 lines
First I will rewrite the existing IPv4 over Firewire driver to use the notification mechanisms and also generate the RFC2734 ARP packets in the arp code.
Then I'll implement the IPv6 stuff based on that IPv4 solution.
I even think that we do not need to have event notification if we can just use
max_rec, sspd and fifo embedded in the destination "MAC address" in the sending packet.
Yes and no. After a bus topology change, it takes a brief period for firewire-core to have the new node(s) scanned and tell firewire-net about them, so that firewire-net can add (or remove) items in the list for the mapping between GUID on one hand and card:generation:nodeID on the other hand.
So, right after a bus reset, we may already receive IP packets from nodes which firewire-core didn't process yet. But I guess this short period isn't really a problem.
By the way, I wouldn't trust max_rec and sspd from 1394-ARP or 1394-NDP packets. These should rather be taken from firewire-core's bus analysis as soon as this is complete. Only unicast_FIFO can alas not be obtained by bus analysis. (IEEE 1394 addendum B:2002 made things more complicated with regard to maximum payload and maximum transmission speed then they were until addendum A:2000, in ways that the authors of RFC 2374 and 3146 surely could not anticipate.)
Signature · 10 lines
Stefan Richter -=====-===-= ---= ===-- http://arcgraph.de/sr/ ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
Quoted 4 lines · Stephan Gatzka
Quoted 2 lines
And, firewire driver does not seem to support zerocopy (fragmented skb) support. It help performance.
O.k., good point. I will have a look into that. But I suggest to not mix up this issue with the IPv6 over firewire enhancement. That should be a separate patch.
I agree, but do we have to two fifos? for what?
If it is for performance, zerocopy should help.
--yoshfuji
Quoted 12 lines · On Jan 20 Stephan Gatzka wrote:
Quoted 9 lines · YOSHIFUJI Hideaki
My current position is to change "mac address" to
struct fwnet_hwaddr { u8 guid[8]; u8 max_rec; u8 sspd; u8 fifo[6]; };
Quoted 3 lines
That is something I'm not really convinced of. As Stefan Richter pointed out clearly, the fifo address might be different between IPv4 and IPv6 communication.
If it is of any help, the initial implementation could assume that IPv4 unicast_FIFO and IPv6 unicast_FIFO are the same. RFC 3146 is silent on this topic (which means it can be one way or the other), but from an implementation point of view, using one FIFO offset for both seems quite natural. Currently the only existing RFC 3146 implementation which is known to us is Mac OS X, and since your tests with OS X 10.6 went well, they obviously use one offset for both protocols.
But if we actually put this assumption into the implementation now, we should make sure that we can easily expand the implementation later in the event that a third implementation comes across which uses separate unicast_FIFOs.
Signature · 3 lines
Stefan Richter -=====-===-= ---= =-=-= http://arcgraph.de/sr/
Quoted 25 lines · Stefan Richter
Quoted 12 lines · On Jan 20 Stephan Gatzka wrote:
Quoted 9 lines · YOSHIFUJI Hideaki
My current position is to change "mac address" to
struct fwnet_hwaddr { u8 guid[8]; u8 max_rec; u8 sspd; u8 fifo[6]; };Quoted 3 lines
That is something I'm not really convinced of. As Stefan Richter pointed out clearly, the fifo address might be different between IPv4 and IPv6 communication.
If it is of any help, the initial implementation could assume that IPv4
unicast_FIFOand IPv6unicast_FIFOare the same. RFC 3146 is silent on this topic (which means it can be one way or the other), but from an implementation point of view, using one FIFO offset for both seems quite natural. Currently the only existing RFC 3146 implementation which is known to us is Mac OS X, and since your tests with OS X 10.6 went well, they obviously use one offset for both protocols.
Quoted 4 lines
But if we actually put this assumption into the implementation now, we should make sure that we can easily expand the implementation later in the event that a third implementation comes across which uses separate
unicast_FIFOs.
Well, FIFO for which side?
I do believe sender will not (or say, must not) care if they use different FIFO for both protocol or not.
Assume that peer has FIFO per protocol, one for IPv4 and another for IPv6. ARP advertise FIFO for IPv4 and NDP advertise FIFO for IPv6. neighbour subsystem has protocol dependent tables, and two different NCEs (neighbour cache entries) will be created. So, sender will correctly get FIFO from NCE for each protocol.
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
Quoted 26 lines · On Jan 21 YOSHIFUJI Hideaki wrote:
Quoted 25 lines · Stefan Richter
Quoted 12 lines · On Jan 20 Stephan Gatzka wrote:
Quoted 9 lines · YOSHIFUJI Hideaki
My current position is to change "mac address" to
struct fwnet_hwaddr { u8 guid[8]; u8 max_rec; u8 sspd; u8 fifo[6]; };Quoted 3 lines
That is something I'm not really convinced of. As Stefan Richter pointed out clearly, the fifo address might be different between IPv4 and IPv6 communication.
If it is of any help, the initial implementation could assume that IPv4
unicast_FIFOand IPv6unicast_FIFOare the same. RFC 3146 is silent on this topic (which means it can be one way or the other), but from an implementation point of view, using one FIFO offset for both seems quite natural. Currently the only existing RFC 3146 implementation which is known to us is Mac OS X, and since your tests with OS X 10.6 went well, they obviously use one offset for both protocols.
Quoted 6 lines
Quoted 4 lines
But if we actually put this assumption into the implementation now, we should make sure that we can easily expand the implementation later in the event that a third implementation comes across which uses separate
unicast_FIFOs.Well, FIFO for which side?
Our Linux implementation should expose a single unicast_FIFO for reception of both protocols, just in case that another implementation expects just this.
For transmission, we should be ready to keep an IP-peer-to-1394-node mapping with per-protocol unicast_FIFOs, but in my mind it is doubtful that any such implementation exists (hence we could just stand prepared to implement it later when proven to be needed -- if this simplifies the initial implementation notably).
Quoted 8 lines
I do believe sender will not (or say, must not) care if they use different FIFO for both protocol or not.
Assume that peer has FIFO per protocol, one for IPv4 and another for IPv6. ARP advertise FIFO for IPv4 and NDP advertise FIFO for IPv6. neighbour subsystem has protocol dependent tables, and two different NCEs (neighbour cache entries) will be created. So, sender will correctly get FIFO from NCE for each protocol.
OK.
Signature · 3 lines
Stefan Richter -=====-===-= ---= =-=-= http://arcgraph.de/sr/
Quoted 4 lines
[ARP and NDISC]
- both can be handled in more natural way.
-- You will not need to mangle those packets when
sending/receiving.
This is also true if we introduce a function pointer. My last implementation does not mangle packets in the driver.
Quoted 3 lines
-- You do not need to inspect ARP/NDISC packet.
By using netevent notification mechanism, you can learn peer parameters.
That is worth to investigate. Will I get notifications when a ARP/NDISC will be send or only if the stack received ARP/NDISC packets? However, I can't see how this will help to get the firewire specific information into the ARP/NDISC packet. This has to be done either via the suggested function pointer or your extension of the mac address.
Quoted 5 lines · Stephan Gatzka
Quoted 4 lines
[ARP and NDISC]
- both can be handled in more natural way.
-- You will not need to mangle those packets when
sending/receiving.
Quoted 7 lines
This is also true if we introduce a function pointer. My last implementation does not mangle packets in the driver.
Quoted 3 lines
-- You do not need to inspect ARP/NDISC packet.
By using netevent notification mechanism, you can learn peer parameters.That is worth to investigate. Will I get notifications when a ARP/NDISC will be send or only if the stack received ARP/NDISC packets? However, I can't see how this will help to get the firewire specific information into the ARP/NDISC packet. This has to be done either via the suggested function pointer or your extension of the mac address.
Netevent example: drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:netevent_cb(). It will be notified when NCE has been updated (by ARP/NDP, in most cases).
Yes, it is for learning Uniq-ID and FIFO from peer.
To send our Uniq-ID and FIFO to peer via ARP/NDP, I am proposing to use extended MAC. This will also help MCAP implementation, without big change in IPv4/IPv6 or even whole net stack.
--yoshfuji
Quoted 22 lines · Stephan Gatzka
I've implemented IPv6 over firewire. Right now I'm facing the problem that the corresponding RFC3146 requires very firewire specific information sent during neighborhood discovery.
There was already a discussion on the linux1394 mailing list
(http://sourceforge.net/mailarchive/message.php?msg_id=30342089 and http://sourceforge.net/mailarchive/forum.php?thread_name=50E4A3E5.8080304%40gmail.com&forum_name=linux1394-devel)During that discussion all participants agreed that it makes no sense to introduce a dependency between the ndisc code and the firewire net driver.
So the most appealing option seems to be to introduce on more callback routine either in struct
net_deviceor structnet_device_ops:int (*ndo_fill_llao)(void *llao);
Because I'm not so familiar with the structure of the whole network infrastructure in Linux, I need some advice if struct
net_deviceor structnet_device_opsis the right place.
Quoted 6 lines
Maybe it's worth to generalize this and do the same for IPv4/ARP because right now the ARP packets are mangled in the firewire net driver.
Nevertheless, I've to admit that right now it seems that only IPv6 over firewire requires such a callback routine.
I'm no expert on firewire requirements, but if you go down the path of adding a net_device_ops member, I'd recommend adding a pointer to your own struct of ops. This would be similar to wireless ops.
Only a suggestion, since you may still need to add more ops later on, and this way you can contain the inflation to a firewire-specific struct of function pointers.
Cheers,
-PJ
Quoted 9 lines
I'm no expert on firewire requirements, but if you go down the path of adding a
net_device_opsmember, I'd recommend adding a pointer to your own struct of ops. This would be similar to wireless ops.Only a suggestion, since you may still need to add more ops later on, and this way you can contain the inflation to a firewire-specific struct of function pointers.
Thanks for your note. Right now I only need on function pointer for filling RFC3146 information and I can imagine doing the same for IPv4/ARP which would be a second function.
Stephan
Quoted 5 lines · On Jan 21 Stephan Gatzka wrote:
Quoted 4 lines · Peter P
I'm no expert on firewire requirements, but if you go down the path of adding a
net_device_opsmember, I'd recommend adding a pointer to your own struct of ops. This would be similar to wireless ops.
Quoted 8 lines
Quoted 4 lines
Only a suggestion, since you may still need to add more ops later on, and this way you can contain the inflation to a firewire-specific struct of function pointers.
Thanks for your note. Right now I only need on function pointer for filling RFC3146 information and I can imagine doing the same for IPv4/ARP which would be a second function.
There is a limited count of IEEE 1394 specifics:
a) RFC 2734 ARP: currently implemented by inspecting and mangling ARP packets within the firewire-net driver (inbound as well as outbound packets).
b) RFC 2734 MCAP (Multicast Channel Allocation Protocol): currently not implemented; not sure if needed (I see a few big downsides to using per-multicast-group channels); not sure if networking core support would be needed for this
c) RFC 2855 DHCP for IEEE 1394: currently not implemented; not sure if needed; not sure if it would concern the kernel at all
d) RFC 3146 NDISC (Neighbor Discovery Protocol for IPv6): That's the only real problem in search of a solution.
I bet there won't be any additional RFCs invented for networking over 1394, ever.
Signature · 3 lines
Stefan Richter -=====-===-= ---= =-=-= http://arcgraph.de/sr/
Quoted 4 lines · Stefan Richter
b) RFC 2734 MCAP (Multicast Channel Allocation Protocol): currently not implemented; not sure if needed (I see a few big downsides to using per-multicast-group channels); not sure if networking core support would be needed for this
It is definitely needed because we need to listen on multicast group for NDP, which might have already had its own channel.
MCAP sends "multicast group address", which is whole IP address. In IP stack we only manages listening groups by special "link-layer address" mapped by device specific transform function. See net/ipv6/ndiscc:ndisc_mc_map() for IPv6.
I am proposing to extend MAC address to 16 bytes long so that we can "map" whole IPv6 address into the "MAC".
On tx on fwnet, it can determine if the destination is multicast or not by either by
- Checking protocol, and looking into protocol dependent multicast range
or
- Checking "EUI-64" group bit (here, we assume all node do not set it in its unique Id, and we map IPv6 multicast and IPv4 multicast in special way; e.g.
ff00::/8 (which has "multicast bit" set)
0100::/96 (which is also "multicast bit" set)
--yoshfuji
Quoted 9 lines · YOSHIFUJI Hideaki
Quoted 4 lines · Stefan Richter
b) RFC 2734 MCAP (Multicast Channel Allocation Protocol): currently not implemented; not sure if needed (I see a few big downsides to using per-multicast-group channels); not sure if networking core support would be needed for this
It is definitely needed because we need to listen on multicast group for NDP, which might have already had its own channel.
Sorry, this was unclear and incorrect. RFC3146 Section 9 (IPv6 Multicast) says that packets for all-nodes/all-routers/ solicited-node multicast addresses must be sent via broadcast channel. So, NDP should work without MCAP.
But, even so, I do not want to have broken implementation without MCAP, or at least, we need prepare to support full multicast. I do NOT want to have patchy implementation just for NDISC.
With extended MAC, networking core (including IPv4/IPv6) does not need to be changed very much for supporting MCAP; no new hooks, no new callbacks.
--yoshfuji