Re: LDL Driver: cannot send to arbitrary LLC (802.2) DSAP
Dave Grothe <[email protected]>
| Newsgroups | gmane.linux.kernel.streams |
|---|---|
| Message-ID | <6.1.2.0.2.20040917084705.0c0663c0@localhost> |
Not a problem. Sorry about the confusion between "raw" and "transparent".
This is Ole Husgaard's code so I deferred to him concerning such
details. I put the raw mode in as a compromise that would allow me to do
the custom filtering that I wanted while deferring to Ole's choices for the
other modes.
-- Dave
At 04:52 AM 9/17/2004, Tim Brown wrote:
>Dave,
>
>Sorry if I've come across as rude and (or) stupid. In the last month
>I've had problems with large software companies not implementing
>standard interfaces to, well, standards. And it's starting to gnaw
>at me. Sorry to be sending it
>
>The LiS software is an absolute godsend, and aside from a couple of
>hacks that I had to make in my 2.6 kernel headers (multiple structure
>declarations), it has built and runs superbly.
>
>With the exception of this SSAP==DSAP filtering; with this switched off it
>works very similarly to the AIX and Solaris drivers. So I was surprised
>that code had been ADDED (i.e. not a case of laziness or sloppiness) to do
>the filtering.
>
>For now, I'm just going to hack the code out - I see no need to go to the
>raw layer. But is there a "better", more "correct" way of dealing with this
>so other users of ldl can benefit?
>
>I didn't recognise the word "transparent", since all the way through the
>ldl driver you use the word "raw" more often.
>
>Good work, keep it up :-)
>
>Regards
>
>Tim.
>
>Dave Grothe wrote:
>>At 10:45 AM 9/16/2004, Tim Brown wrote:
>>
>>>Dave,
>>>
>>>What do you mean by: "The Transparent Mode"?
>>
>>I don't have time to give you the cookbook, but if you look at the ldl
>>driver (and, who knows, perhaps even its documentation) there are
>>different modes of operation that are controlled by how you do the
>>dl_attach. One is a transparent mode in which your driver gets to see
>>all of the incoming Ethernet packets.
>>-- Dave
>>
>>>tim
>>>
>>>Dave Grothe wrote:
>>>
>>>>I have been using the transparent mode in order to avoid this kind of
>>>>thing. My driver does its own filtering of addresses and SAPs.
>>>>-- Dave
>>>>At 09:33 AM 9/16/2004, Tim Brown wrote:
>>>>
>>>>>I am porting some network multiplexor software which uses multiplexes
>>>>>messages between hosts and processes on hosts using 802.2 DSAP/SSAP
>>>>>addressing.
>>>>>
>>>>>I bind onto a DSAP, allowing me to listen for Ethernet frames addressed
>>>>>to me. Within those packets is the return address for me to send my
>>>>>replies
>>>>>to. This may or may not be the Ethernet address of the sender.
>>>>>
>>>>>I then wish to send a frame to the destination which may have an arbitrary
>>>>>DSAP. However, in eth_8022_mkhdr() in drivers/str/linux/ldl.c line:1704
>>>>>
>>>>> if (dsap != dl->sap->sap.sap[0]) {
>>>>> struct sap *sap;
>>>>>
>>>>> for (sap = dl->subs; sap; sap = sap->next_sap)
>>>>> if (dsap == sap->sap.sap[0])
>>>>> break;
>>>>> if (sap == NULL)
>>>>> return 0;
>>>>> }
>>>>>
>>>>>i.e. if you are not bound to "dsap", or have an additional binding
>>>>> to "dsap", then the message isn't sent.
>>>>>
>>>>>I am using LiS 2.17.U.
>>>>>
>>>>>I don't believe this behaviour is correct, since it is inconsistent
>>>>>with the Solaris and AIX DLPI drivers, as well as the understanding
>>>>>of most people here of how DSAP/SSAP addressing works; i.e. you bind
>>>>>onto and listen on a DSAP (or multiple DSAPs), but any process on any
>>>>>station can transmit to any of the available SSAPs.
>>>>>
>>>>>Therefore, I don't believe there is any reason for this code. Is there?
>>>>>
>>>>>Regards,
>>>>>
>>>>>Tim
>>>Linux-streams mailing list
>>>[email protected]
>>>http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
>
>--
>Tim Brown <[email protected]> | City Computing Limited |
>T: +44 20 8770 2110 | City House, Sutton Park Road |
>F: +44 20 8770 2130 | Sutton, Surrey, SM1 2AE, GB |
>BEAUTY: What's in your eye when you have a bee in your hand.__________/
>
>_______________________________________________
>Linux-streams mailing list
>[email protected]
>http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams