From: James K. <jke...@li...> - 2005-08-04 18:26:32
|
Kevin G=F6ser wrote: >Am Donnerstag, 4. August 2005 17:33 schrieben Sie: > =20 > >>Kevin G=F6ser wrote: >> =20 >> >>>Hi, >>> >>>I just checked if the same thing happens with other traffic, too. It d= oes! >>>For example http packages are also sent with the wrong mac address as >>>source. However, the answers are always sent to the correct mac addres= s. >>>So this isn't dhcpcd related, is it? I'm not sure if dhcpcd still coul= d be >>>responsible for this. Any idea? >>> =20 >>> >>What version of the ipw2200 driver are you using? If not using 1.0.6 >>and ieee80211-1.0.3, can you upgrade to those? >> =20 >> > >Sorry, I'm already up to date :-/ Is there anything which could proof th= at it=20 >is not a driver thing? > =20 > Hmmm. When a socket buffer is passed to the ieee80211 subsystem, it uses the socket buffer as if it owns it (which it does) and overwrites the 802.3 header with an 802.11 SNAP header. If that frame is then re-used, the 802.3 header is no longer present (it has been overwritten w/ the SNAP)=20 This could explain what you are seeing. Yi -- if you have time during your day today, can you take a look at this? We should be able to modify ieee80211_tx's ieee80211_xmit() method so that it doesn't have to overwrite the incoming SKB and can just stick the snap on the first TXB constructed. If I have some more free time today I'll take a crack at it and send out a patch if I get it done. If you don't see a patch from me for the above, assume I didn't get to look into it further. James |
From: James K. <jke...@li...> - 2005-08-04 19:05:05
Attachments:
ieee80211-1.0.3-skb_corrupt.patch
|
James Ketrenos wrote: >Yi -- if you have time during your day today, can you take a look at >this? We should be able to modify ieee80211_tx's ieee80211_xmit() >method so that it doesn't have to overwrite the incoming SKB and can >just stick the snap on the first TXB constructed. If I have some more >free time today I'll take a crack at it and send out a patch if I get it >done. If you don't see a patch from me for the above, assume I didn't >get to look into it further. > > Alright; I had few minutes. Try the attached (it runs here, don't know if it will solve the problem though) % cd ieee80211-1.0.3 % patch -p1 < ieee80211-1.0.3-skb_corrupt.patch James |
From: Kevin <kg...@in...> - 2005-08-04 20:30:29
|
Am Donnerstag, 4. August 2005 21:04 schrieb James Ketrenos: > James Ketrenos wrote: > >Yi -- if you have time during your day today, can you take a look at > >this? We should be able to modify ieee80211_tx's ieee80211_xmit() > >method so that it doesn't have to overwrite the incoming SKB and can > >just stick the snap on the first TXB constructed. If I have some more > >free time today I'll take a crack at it and send out a patch if I get it > >done. If you don't see a patch from me for the above, assume I didn't > >get to look into it further. > > Alright; I had few minutes. Try the attached (it runs here, don't know > if it will solve the problem though) > > % cd ieee80211-1.0.3 > % patch -p1 < ieee80211-1.0.3-skb_corrupt.patch Thanks a lot! The patch works, no more mac address troubles :) Cheers! Kevin |
From: Zhu Yi <yi...@in...> - 2005-08-05 08:34:38
Attachments:
pskb_header.patch
|
On Thu, 2005-08-04 at 14:04 -0500, James Ketrenos wrote: > James Ketrenos wrote: > > >Yi -- if you have time during your day today, can you take a look at > >this? We should be able to modify ieee80211_tx's ieee80211_xmit() > >method so that it doesn't have to overwrite the incoming SKB and can > >just stick the snap on the first TXB constructed. If I have some more > >free time today I'll take a crack at it and send out a patch if I get it > >done. If you don't see a patch from me for the above, assume I didn't > >get to look into it further. > > > > > Alright; I had few minutes. Try the attached (it runs here, don't know > if it will solve the problem though) You are right. The skb is shared between ieee80211_xmit and PF_PACKET socket (if any). So if we change it in the stack, the raw socket will also see the change. I think it is another good reason for the native ieee80211 stack. If we process protocol headers in network stacks instead of dev->hard_start_xmit, we won't have this kind of problem. Currently I think making a copy to the skb can solve it well. You patch is correct. Another apporach is using skb_unshare() at the beginning of ieee80211_xmit(). It will copy another skb only if the skb is cloned. So the overload is also small. I've attached the patch FYI. Thanks, -yi |
From: James K. <jke...@li...> - 2005-08-05 16:58:58
|
Zhu Yi wrote: >You patch is correct. Another apporach is using skb_unshare() at the >beginning of ieee80211_xmit(). It will copy another skb only if the skb >is cloned. So the overload is also small. I've attached the patch FYI. > > I'll keep the current approach since there is no (vs. small) overhead associated w/ using PF_PACKET sockets then. Thanks for checking into this. James |