Bug 269 - ad-hoc problem for Dell D505
: ad-hoc problem for Dell D505
Status: VERIFIED FIXED
: IPW2100
Install
: 0.29
: Dell RedHat
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency treegraph
 
Reported: 2004-10-08 19:43 by
Modified: 2005-10-23 03:28 (History)


Attachments
ad-hoc preemption fix (1.63 KB, patch)
2004-11-19 19:40, Rusty Lynch
Details | Diff


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2004-10-08 19:43:33
We see no such problem on our Compaq X1000 and IBM T40, so this problem seems 
to be only related to Dell D505.
steps:
1, On ibm t40:
   % modprobe ipw2200
   % iwconfig eth1 mode ad-hoc essid testing channel 2
   % ifconfig eth1 192.168.2.20 up
2, On dell d505:
   % modprobe ipw2200
   % iwconfig eth1 mode ad-hoc essid testing channel 2
   % ifconfig eth1 192.168.2.21 up
   % ping 192.168.2.20
it displays: Destination Host Unreachable.
but if we use a Compaq X1000 instead of D505 and redo the above steps,we    
can communicate with the ibm t40.

but if we change the steps a little, we can communicate using d505.
steps:
1, On ibm t40:
   % modprobe ipw2200
   % iwconfig eth1 mode ad-hoc essid testing channel 2
   % ifconfig eth1 192.168.2.20 up
2, On dell d505:
   % modprobe ipw2200
   % iwconfig eth1 mode ad-hoc
   % iwconfig eth1 essid testing channel 2
   % ifconfig eth1 192.168.2.21 up
   % ping 192.168.2.20
this time, we can communicate with the ibm t40.
------- Comment #1 From 2004-11-12 15:42:10 -------
The ad-hoc code has seen some significant rework.  Please retest with v0.13
------- Comment #2 From 2004-11-17 07:17:56 -------
Please re-test in 0.13 or later.
------- Comment #3 From 2004-11-18 00:01:19 -------
test it again in 0.13, but this time after the association is established and 
the static IP is assigned, the two laptop can't communicate with each other.
the PING gives message: Destination Host Unreachable.
------- Comment #4 From 2004-11-18 16:47:35 -------
Please provide the output of "netstat -nr".
------- Comment #5 From 2004-11-18 16:53:47 -------
another thing... verify that both machines agree on bssid.  Since we are setting
both the channel and essid on both machines, we could end up with two ad-hoc
networks.  (We shouldn't, but if we had a problem with the first scan then
we would fall in to the path for creating a new network.)
------- Comment #6 From 2004-11-18 17:40:16 -------
ok, after moving my setup to my home office, I am not seeing this problem, and
it is not a routing problem.

No need for more information since I can reproduce it now.  As a side note, if I 
force an association from one particular machine of mine (also a dell, but a
different model dell) by doing a "iwpriv eth1 set_mode 4", then I can start
pinging between the two machines.
------- Comment #7 From 2004-11-18 17:42:39 -------
s/am not/am/

There was a mistake in my first sentence. I AM seeing the bug.
------- Comment #8 From 2004-11-18 20:17:29 -------
Even though iwconfig shows the correct bssid, outgoing packets are using what
ever the previous bssid was.  This causes the reported "Destination Host
Unreachable" because the Dell system's arp response uses the wrong bssid, so
the other machine in the network ignores the packets.

------- Comment #9 From 2004-11-18 21:23:24 -------
Indeed, if we don't set channel on both laptops to avoid creating two ad-hoc 
networks, then ad-hoc mode works well:
1, On Compaq X1000:
   % modprobe ipw2200
   % iwconfig eth1 mode ad-hoc essid testing channel 2
   % ifconfig eth1 192.168.2.20 up
2, On Dell D505:
   % modprobe ipw2200
   % iwconfig eth1 mode ad-hoc essid testing
   % ifconfig eth1 192.168.2.21 up
   % ping 192.168.2.20
   we can see ping comes back with data.
------- Comment #10 From 2004-11-19 19:40:39 -------
Created an attachment (id=103) [details]
ad-hoc preemption fix

Well, as it ends up this is actually a preemption bug.	It just so happens that
my Dell system was built with preemption enabled, and my other two systems were
not.

We were sending a host command to create a new ad-hoc network, and then storing
our bssid in private data in the next line of code.  With preemption enabled it
is actually possible for the return notification to execute before we get to
the next line of code.	The fix will be in v0.14, and here is a patch for who
ever wants it.
------- Comment #11 From 2004-11-19 19:41:22 -------
fixed in v0.14
------- Comment #12 From 2004-11-22 17:58:13 -------
can't verify the fix, because we can't set correct channel under ad-hoc, see 
bug 413. will verify this when bug 413 is fixed.
------- Comment #13 From 2004-11-25 00:42:27 -------
verified in 0.15.