Bugzilla – Bug 488
Cannot communicate with bridged hosts in ad-hoc mode
Last modified: 2006-04-03 13:07:49
You need to log in before you can comment on or make changes to this bug.
I have a network which is part ad-hoc wireless and part wired, with a bridge across the two. Unfortunately, any unicast traffic in this situation is dropped even when it can be delivered (multicast - such as DHCP - works fine). The problems is that ipw_find_station() returns IPW_INVALID_STATION on hosts that are on the wired part of the network. For non-unicast addresses, the driver adds a station - extended this behaviour to all addresses (including unicast) makes the driver 'work' (I'm currently writing this over a wireless ipw2200 connection using this modification to the driver).
System 1 <-> Wired <-> System 2 <-> Ad-Hoc <-> System 3 Is the above the basic configuration, where the problem is that System 3 is trying to send a packet to System 1, but it is not working? How is your system configured for routing, default gateway, etc? The way I thought it was supposed to work is that System 2 would need to be configured as your wired-to-wireless gateway/router--any packets being sent from System 3 would be routed through System 2 as such. With the change you suggest, it sounds like System 3 would send an 802.11 Ad-Hoc frame as if System 1 is a part of the Ad-Hoc network. The configuration of System 2 would then be such that it will pull down those Ad-Hoc frames and forward them to System 1? I want to make sure I understand what all is needed across both the Tx and Rx code paths.
The diagram is correct, yes. However, ignore routing/default gateway - that's not relevant. They are all exist on the same subnet; no routing is required. System 1 cannot talk to System 3, but while sniffing on the wireless network shows packets arriving from System 1, sniffing on the wired shows none arriving from System 3. It seems you have in mind a wireless<->wired router; that's not how this is setup - System 2 is configured as an ethernet bridge. In this instance it's just a Windows XP box; with one wired and one wireless interface in the bridge. I didn't find anything was needed in RX - System 2 is correctly configured, it was simply that the driver was refusing to send the packet because it didn't recognise the station.
Assigning to James, per scrub.
I've incorporated the change per initial bug description into 0.20
I would like to advice that this bug ( or a similar ) will be reopen as the same behavior is present in ipw2200 1.0.1 When configuring in adhoc mode, the driver is not able to "ear" the unicast traffic. Scenario: Laptop A (tested with prims based minipci card, orinoco pcmcia cards and cisco pcmcia cards): iwconfig wlan1 essid "MySid" mode ad-hoc ifconfig wlan1 up 192.168.2.20 Laptop B ( intel 2200/2915 minipci card ipw2200 1.0.1 fw 2.2 ): iwconfig eth1 essid "MySid" mode ad-hoc ifconfig eth1 up 192.168.2.21 When doing ping from A to B I can see with tcpdump: on Laptob B the arp request ,and the arp reply, but can't see other traffic. on Laptop A The arp request, the arp Replay the icmp echo request. When doing ping from B to A I can see with tcpdump: On Laptop B the arp request, the arp Replay the icmp echo request. on Laptop A The arp request, the arp Replay the icmp echo request, and the icmp echo reply Obviously the pings in both case are never able to complete. Just for testing I also started on Laptop A a dhcp client on wlan interface and on Laptop B, always using tcpdump I can the the dhcp request. To be sure that nothing in kernel or config was wrong I also inserted two different cards ( orinonco and cisco ) and changed the minipci ( with an Atheros AR5212 ) on Laptop B and issued the same configuration and everything works. If needed more info feel free to contact me at pigi__at__frumar__dot__it
From scrub: logics_sbux #488 -- i think we know the cause for this problem logics_sbux the network_packet check used for detecting packets sent by the client is checking the wrong address
Created an attachment (id=278) [details] Alters how network_packets are identified Please try this patch and see if it resolves the problem with packets not coming through.
Setting to 'needsmoredata' until we find out if the attached patch fixes the problem identified. Thanks, James
The attachment 278 [details] implemented "filter out packets not sending to me". But he intention for is_network_packet is to "filter out my own packets". Note it is not in monitor mode, so the latter one is more direct. The is_network_packet code in 1.0.1 is buggy because it uses the wrong SA for Ad-hoc mode. Below patch addressed this bug.
Created an attachment (id=284) [details] is_network_packet ibss fix
OK , the patch from ZhuYi works . But a minor problem , this patch has a conflict with patch (id=276) about bug 385. I used ZhuYi's code .
The bug is fixed in ipw2200 1.0.3.
Mark it as fixed.
OK, I've tested the ad-hoc mode against ipw2200-1.0.3 . It worked fine.