Networking help pls?

[guddler]

Hi all,

The wireless has crapped out on my ADSL router again. Frankly, I'm getting fed up with wireless routers lasting just beyond their warranty period (I've had this about 14 months) and then becoming unreliable as hell!! But that's another matter that I'll be taking up with BroadbandBuyer on Monday!

So, I've disabled the wireless part of the router, and the router is stable again.

When I got my Naomi I bought one of these: http://wifibridge.co.uk/ and used it to extend my wifi by using it in bridged mode. Sadly, it only has a wifi bridge mode, not a wired to wireless bridge mode so I've had to set it up in router mode now.

That works, but what it means is that I now have two networks. And I'm double natting. So anything wireless picks up a 192.168.1.0 address, anything wired, a 172.16.5.0 address. Again, so far so good (bear with me!). Because the router is on the 172.16.5.0 network, traffic inherently flows from wireless to wired. I've added a static route to the ADSL router and traffic can now flow from wired to wireless and you can ping, transfer files and so on. So in theory, all is peachy, right?

Well, wrong. Everything that relies on any form of auto-discover doesn't work. So, I have Sonos audio components and you can't see them from the wireless network unless you plug a cable in and pick up a wired IP as well (which obviously I can't do from phones and tablets). OS X network discovery doesn't work. You can only 'Go to server' from wireless if you specify the IP. Apple AirDrop doesn't work, the two networks don't see each other!

Is there anything else I can set up and / or change to get this last bit working, or am I going to have to buy yet another new router that will no doubt last 12 months.

For info, on the wired network I run a W2K12 server that does DNS & DHCP (plus many other things). The wireless bridge is doing DHCP for the 192 side.

If you read this far - thanks!!

guddler2013-11-23 12:49:29

 

[simonden]

OK, I don't have the same wifibridge as you, but generally to turn one or these (or any wifi router) into wired to wireless bridge all you do is put it into Router mode and turn off DHCP on the bridge. Can you independently turn off DHCP?

EDIT: and make sure the network port is in WAN mode when you turn off DHCP!

re: the auto-discover, have you tried putting the bridge in 'g' only mode? I have had devices in the past that won't see an 'n' signal. Also check that you haven't accidentally turned on WPS on the bridge.

simonden2013-11-23 13:18:06

 

[andrew96]

yes turn off dchp and assign them fixed ip addresses within the routers range, also make sure the subnet mask is set correctly 255.255.255.0 also the default gateway being the master routers ip as that has the access to the internetandrew962013-11-23 13:45:46

 

[andrew96]

I have a wireless bridge to my mothers house 4 doors down the road (saves her having to pay for internet) it was all very flaky on dchp and when it did fail nothing was connected to each other so it was impossible to get to the bridge's webpage! solved by giving everything fixed ip's, much more stable, and when wireless bridge stops working (thunder storm interference mainly) i can now log in and reboot it as i know its fixed ip addy!!
andrew962013-11-23 13:50:08

 

[guddler]

Dammit - just lost a long reply

I tried disabling DHCP initially and giving it a manual IP but it didn't occur to me to try having an IP on the LAN side and an IP on the WAN side, both within my normal network segment. Sadly when I try this, it doesn't work.

If I give the WAN side the IP 172.16.5.3 and the LAN side 172.16.5.4 then nothing routes from LAN to WAN. And TBH, that doesn't surprise me as my understanding has always been that for a router to route, both sides of the router need to be on separate networks, or it will think there is nothing to be done. And logically, in the example above I can understand this. If I'm a client and I have the IP 172.16.5.78 say, and I try to go to 172.16.5.5 the bridge will just think it's on the same network as me and do nothing. It won't know that actually, 172.16.5.5 is a server on it's WAN side and it therefore route traffic for it.

That's what static routes are for but there's nowhere to enter them in this little gizmo.

So I think that I have to have two different networks, one on the WAN and one on the LAN for it to route don't I ?? Or am I barking up the wrong tree and missing something obvious?

PS: I actually know a fair bit about this as I manage the cloud infrastructure of a Swiss government owned company. I'm just a bit stuck trying to work out if I can make this do something that I guess it wasn't designed to do??

 

[andrew96]

PS: I actually know a fair bit about this as I manage the cloud infrastructure of a Swiss government owned company. I'm just a bit stuck trying to work out if I can make this do something that I guess it wasn't designed to do??

Ah right, your know a lot more about it than me then! I will bow out, good luck

 

[guddler]

Hmm, I've got a feeling I'd need to disable NAT completely in the Wi-Fi bridge to get it to behave completely. There's no option for it, and I just tried telnet and SSH to the bridge and both were refused so I'm guessing there's probably no hope. Maybe I'll have another play later!

 

[guddler]

Couple more observations...

I tried wireless G only mode and it doesn't seem to make any difference. Shame, while it would have been slow, I could live with it.

Also, in the background, on my wired network my gaming PC is downloading a 6.5GB game through Steam. I noticed that when I tried having both sides of the wireless bridge on the 172 network the transfer rate on the gaming PC dropped from 2.1Mb to around 300Kb (K?k?, whatever!). There's not really any rhyme or reason for that other than maybe the bridge is then doing something odd and gobbling up packets into a black hole like a mad man!!!

Got relatives round shortly so I've put it back to how is was for now but I'll have another go when I get a chance!

 

[trm]

Hi dude,

is this a fair representation of your network?

I'll bet that the auto-discover stuff is screwed because of the NAT ocurring on wifibridge. The OS X stuff uses Bonjour (I assume) and that's going to do a mDNS at best and a .255 broadcast at worst. Can't tell whether the wifibridge NAT will grok mDNS or leave it alone, but I'd be surprised if it's got IP multicast support in there.

The wifibridge web page talks about it being able to act as a wireless switch and they refer to the ethernet as the LAN or WAN port. The specs don't exactly read as if they were written by somebody who understands the words they're using so I don't know if they're chucking that in there as marketing bollocks or whether it will actually run as a wireless switch, or as an AP without NAT?

But all of this is definitely happening above layer1 so the B/G/ACNTHEKLF is a red-herring as is DHCP.

 

[guddler]

That's a spot on diagram - vastly simplified, but yeah!

And I guess it is going to be the double NAT causing the issue. Just wondering if there's anything I can do.

What's RIP. Does that have any bearing as I think I can do something with RIP on my server and possibly on my main router.

 

[trm]

RIP is an early routing protocol. It's not going to help because that only serves to show interconnect paths and costing.

The problem is that the wifibridge isn't being completely valid in routing between its two interfaces. I reckon if you put wireshark on the wired side and triggered some Bonjour activity on the wifi side you wouldn't see any multicast packets being pushed over from wifi to wired or if you do, the wifibridge isn't multicasting them out when it receives responses.

This sort of stuff seems to ignored by anything which thinks it's going to be an edge device. Annoying though that there's no option for it.

Before we figure you can't get this config working it might be an idea to do some wireshark sniffing on the wired net looking for anything with a source ip of 224.0.0.251 when you trigger Bonjour activity on the wifi side and then the wired side.

 

[guddler]

Just done a wireshark sniff on the wireless side and can definitely see the 224.0.0.251 traffic on the wireless side when I start up airdrop (for example). Can also see that Sonos is using 239.255.255.250 for discovery (shown as SSDP), some so similar.

I guess I need to look and see if the same is appearing on the other side?

I'm on Eve Online on the wired side at the moment but after that I'll have a looksie.

Can't say I desperately understand what I'm seeing in WireShark though...

guddler2013-11-24 21:34:49

 

[trm]

Dude, you should escape from Eve before it drags you in. You're too young to lose the rest of time to it

Would be interested to find out what you see on wired when generating Bonjour events on wireless.

And mail me the pcap from wire shark if you like. Initially it's about the presence of multicast traffic (UDP, port 5353?) but at some point the contents could be valuable.

 

[guddler]

Did a capture on both sides last night. Was too late to be sorting it out properly so I'll do that tonight but basically, as suspected there's no sign of the multicast traffic making it across from one network to the other.

I did however discover that my main router has a fantastic telnet based configuration mode implemented so you never know there may be something can be done on that end. It's possible to set up a second LAN, virtual LANs, IGMP snooping and all sorts. Don't know if any of it would help or not, going to have a think tonight.

 

[Setch]

Can you set the bridge as a DMZ to negate the NAT and rely on the routers NAT to keep you secure ?. I'm sure I've done this in the past to get round a similar issue.. Ignore if I'm talking out of my arse

 

[guddler]

Erm, I can certainly try! It's got a DMZ feature. Will give it a go

 

[trm]

I don't think IGMP snooping is going to help unfortunately. The problem seems to be that the bridge in any mode isn't considering multicast traffic as something which needs routing out of its ethernet interface, cos we don't see any Bonjour events pass wireless to wired. I suspect the bridge is just dropping them on the floor, and not even bridging broken (via NAT or something equally nasty) mDNS packets.

IGMP snooping probably won't help because the mDNS stuff is super half-assed (for a legitimate reason) multicast. Nothing requests multicast group membership or issues/receives any kind of IGMP packet because mDNS is stateless.

Could you dropbox me a wireshark from the wired side showing multicast activity? What we really need is to be able to add a static route into the bridge's routing table to cover the mDNS IP range and fake it as though it's an actual network, hopefully overriding some internal packet filter option which has it dropping them.

Saying that can you configure any firewall options on the bridge? Might be worth seeing if they purposefully or accidentally use the firewall pf to stop multicast leaking through the ethernet port, and if so whether disabling the pf stops them being dropped.

 

[guddler]

Hiya - whilst an interesting option (making the bridge itself a DMZ host) it didn't help. My guess is, like Tim says it's just not arsed to do anything with multicast packets at all!

Will drop you a wireshark shortly. There is indeed some limited firewall stuff on the bridge. Nothing like as good as on the router but some. It's very user friendly though so I have a feeling it won't let us enter much that could trick it. We'll see...

guddler2013-11-25 20:06:37

 

[guddler]

Delivered. That's a capture of both the wired and wireless sides. Wireless from my gaming rig (Windows) wireless from my MacBook Air. During the capture I started Sonos controller up on the Mac which searches for Sonos devices (and fails to find them), and then I started up Air Drop. Which wouldn't find anything as the gaming rig was booted into Windows not OS X but it should still show it trying.

Got to go up the shed to get a PCB ready for shipping but won't be long as it's bloody freezing out there (literally!)

 

[trm]

Right. The bridge is definitely not being kind with multicast and that's causing the problem. It must be doing some sort of null route on it, inbound as well as outbound because I saw none of the wired-originated mcast stuff coming over.

Your OS X client is also trying to do proper multicast at various points by trying to join mcast nets so if you can get some sort of IGMP snooping enabled on your wired router then I'd be interested to see what that shows. I'm not sure how we'd get the snooper exposure to the mcast traffic though because the bridge seems to be firmly keeping it internal.

Also, something with a Sonos originated MAC on the wired side is doing a lot of spanning tree chatter? Bit weird for some remote audio stuff to try to autoconfig via STP! But maybe I'm misinterpreting what it's doing.

The SSDP stuff is more multicast stuff - uPNP (nice that Bonjour and uPNP are so compatible

) and that's getting whupped by the bridge too it seems, which isn't surprising.

It looks like you have a TVersity on the wired side offering itself up with NOTIFYs and a Zoneplayer on the wireless side MSEARCHing for stuff. Neither of these appear to be aware of each other, nor are they currently getting any registrations within the multicast group.

(I've made the assumptions that your OS X has IPv4: 192.168.1.151 and IPv6 fe80::8638:35ff:fe51:b412)

If you do find any method of adding a static route into the bridge, I'd add:

net 224.0.0.0/8 to bridge eth0 pri 1

net 239.0.0.0/8 to bridge eth0 pri 1

As this would get both the mDNS queries from your OS X Bonjour stuff working, and the SSDP traffic. Is there a uPNP enable option on the bridge? Under the hood that's probably just removing a pf drop rule for 239/8