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 |