PDA

View Full Version : Wireless bridge question



Puggie
2007-01-19, 05:40
If I connect my server to a squeezebox 2 with the ethernet cable, can I then access the server wirelessly using the Wireless bridge function in the squeezebox, without having to have a seperate wireless access card in the server.

I just want to use a VERY simple stripped down server.

Ramage
2007-01-19, 05:51
I think you are asking whether the SB2 can be used as a Wireless Access Point to access your server.

There are a number of threads on this forum dealing with this, and the bottom line is that the SB2/3 can not be used as a WAP.

Puggie
2007-01-19, 07:51
Thanks

I had searched but most of what I'd found dealt with using the SB as a bridge and I couldn't find anything quite as specific as I wanted.

peter
2007-01-19, 08:20
Ramage wrote:
> I think you are asking whether the SB2 can be used as a Wireless Access
> Point to access your server.
>

Not necessarily. Perhaps he wants his server to access the access point
through the SB3. Unusual solution but it might well work.

Regards,
Peter

Puggie
2007-01-19, 09:08
I want to be able to do a rsync between 2 servers to keep their music folders identical (I will update the main server then rsync to the secondary server). I want to access the secondary server using the SB2 as its wireless connection.

does that make sense?

to expand the application a little, the main server will be in the house, I'll rip all my music to this. the secondary server will be in the car with a squeezebox2. I want to be able to rsync from the main home server to the secondary server in the car using the SB2 in the car as the wireless bridge. The main server will link through the broadband router, the rsync will be done as part of the shutdown routine (when you alarm the car the server in the car will rsync to the house, update with any changes made to the music folder in the house e.g. freshly ripped music I put on the server at home and once updated will shut down).

is this possible?

Ramage
2007-01-19, 09:16
Your intentions are now a little clearer.

I think you will be able to do what you want, as the SB2 will connect the server in the car to your wireless network in the house and the second server.

Quite a novel project.

Good luck

Puggie
2007-01-19, 10:12
Cool! I'm trying to set up a single server for home with all my music stored as FLAC to retire my cd collection, I can then access this from anywhere in the house (and work), all my music at the touch of a button. I then want to duplicate this in the car so I have all my music available there too :) the issue is making it so I rip new material to the main server and the rest of the process is automatic.

peter
2007-01-19, 10:25
Puggie wrote:
> Cool! I'm trying to set up a single server for home with all my music
> stored as FLAC to retire my cd collection, I can then access this from
> anywhere in the house (and work), all my music at the touch of a
> button. I then want to duplicate this in the car so I have all my music
> available there too :) the issue is making it so I rip new material to
> the main server and the rest of the process is automatic.
>

It's a cool project. Someone else here had built an SB (1 or 2) into his
car, with the display in the dashboard. The server, one of these small NAS
boxes, was store in the glove box.

Regards,
Peter

Ramage
2007-01-20, 01:55
Just to test the feasibility of your proposal I set up the following:

* NSLU NAS+Slimserver connected to SB3 with crossover ethernet cable
* Set up wireless bridge to my main network.

Entered all required IP addresses for my network and it worked perfectly.

I am able to connect the SB directly to the Slimserver on the NSLU through the cable and also access the NSLU from my PC over the wireless bridge, as if it was connected directly to the network. The NSLU is also able to access the internet through the default gateway.

Looks like what you propose will work OK

peter
2007-01-20, 02:05
Ramage wrote:
> Just to test the feasibility of your proposal I set up the following:
>
> * NSLU NAS+Slimserver connected to SB3 with crossover ethernet cable
> * Set up wireless bridge to my main network.
>
> Entered all required IP addresses for my network and it worked
> perfectly.
>
> I am able to connect the SB directly to the Slimserver on the NSLU
> through the cable and also access the NSLU from my PC over the wireless
> bridge, as if it was connected directly to the network. The NSLU is also
> able to access the internet through the default gateway.
>
> Looks like what you propose will work OK
>

Excellent. I guess an NSLU, an external harddisk and an SB2 could make a
fully functional car system. I'd be interested in reading more on your
project as it developes. Perhaps I'll go that way myself sometime in the
future. I'm mostly concerned about building an SB2 somewhere in the
dashboard, though...

Regards,
Peter

Mark Lanctot
2007-01-20, 11:06
Just to test the feasibility of your proposal I set up the following:

* NSLU NAS+Slimserver connected to SB3 with crossover ethernet cable
* Set up wireless bridge to my main network.

Entered all required IP addresses for my network and it worked perfectly.

I am able to connect the SB directly to the Slimserver on the NSLU through the cable and also access the NSLU from my PC over the wireless bridge, as if it was connected directly to the network. The NSLU is also able to access the internet through the default gateway.

I'm amazed this all works?

Because this is a convoluted wireless arrangement. Say the SB3 wants to send something to SlimServer. It can't do this over its crossover cable because you've told it to use the wireless interface and bridge the Ethernet port. So it looks for SlimServer out over the wireless interface.

The router sees the packets destined for SlimServer and retransmits them.

The SB3 receieves the packets, detects that they are destined for the bridged device and sends them to the NAS (SlimServer). SlimServer then responds with what the SB was asking for by sending it down the crossover cable. The SB can't see the packets because it's acting as a bridge again since the packets came over the Ethernet interface and sends this over wireless. The router receieves this and retransmits it, which the SB3 finally receives.

Pretty convoluted!

It's great that it works, but how's the bandwidth? Any latency? Can you play FLACs?

Someone tried this once before and it didn't work - I put it on http://wiki.slimdevices.com/index.cgi?NetworkDesign as an example of what NOT to do.

I do not mean any disrespect at all, I'm surprised and amazed that it works!

peter
2007-01-20, 11:35
Mark Lanctot wrote:
> Ramage;172228 Wrote:
>
>> Just to test the feasibility of your proposal I set up the following:
>>
>> * NSLU NAS+Slimserver connected to SB3 with crossover ethernet cable
>> * Set up wireless bridge to my main network.
>>
>> Entered all required IP addresses for my network and it worked
>> perfectly.
>>
>> I am able to connect the SB directly to the Slimserver on the NSLU
>> through the cable and also access the NSLU from my PC over the wireless
>> bridge, as if it was connected directly to the network. The NSLU is also
>> able to access the internet through the default gateway.
>>
>
> I'm amazed this all works?
>
> Because this is a convoluted wireless arrangement. Say the SB3 wants
> to send something to SlimServer. It can't do this over its crossover
> cable because you've told it to use the wireless interface and bridge
> the Ethernet port. So it looks for SlimServer out over the wireless
> interface.
>
> The router sees the packets destined for SlimServer and retransmits
> them.
>
> The SB3 receieves the packets, detects that they are destined for the
> bridged device and sends them to the NAS (SlimServer). SlimServer then
> responds with what the SB was asking for by sending it down the
> crossover cable. The SB can't see the packets because it's acting as a
> bridge again since the packets came over the Ethernet interface and
> sends this over wireless. The router receieves this and retransmits
> it, which the SB3 finally receives.
>
> Pretty convoluted!
>
> It's great that it works, but how's the bandwidth? Any latency? Can
> you play FLACs?
>
> Someone tried this once before and it didn't work - I put it on
> http://wiki.slimdevices.com/index.cgi?NetworkDesign as an example of
> what NOT to do.
>
> I do not mean any disrespect at all, I'm surprised and amazed that it
> works!
>

Perhaps someone changed the squeezebox firmware to allow this. If Ramage
wants to make sure the traffic between the SB and the slimserver is not
going over the wireless interface (twice) he could try switching off the
WAP. If it still works then the traffic obviously stays on the wired
network.

Regards,
Peter

Mark Lanctot
2007-01-20, 11:53
Perhaps someone changed the squeezebox firmware to allow this. If Ramage
wants to make sure the traffic between the SB and the slimserver is not
going over the wireless interface (twice) he could try switching off the
WAP. If it still works then the traffic obviously stays on the wired
network.

Well yes, if you turned off the bridging function and went with the wired interface it would work perfectly, but you could then not access the NAS from a PC and you also couldn't get Internet/SqueezeNetwork access.

Perhaps I'm confused at what the wireless bridge functionality really does in a Squeezebox then. I thought it merely dumbly passed all traffic coming from the wired interface out to the wireless interface for the router to deal with. If it sifts through the incoming wired traffic looking for packets destined for itself, it's acting more like a router than a wireless bridge, right? It would be great if it did that, but then it's not acting as a wireless bridge. Also if there's no SlimServer on the wired interface it's a waste of resources as there will never be any traffic destined for it. So I suspect it does not do this.

Traffic coming over the wireless interface is a little easier to understand - if it sees traffic destined for itself it processes it, if it sees traffic destined for the bridged device it passes it down the wired interface without processing it.

seanadams
2007-01-20, 12:26
I'm amazed this all works?

Because this is a convoluted wireless arrangement. Say the SB3 wants to send something to SlimServer. It can't do this over its crossover cable because you've told it to use the wireless interface and bridge the Ethernet port. So it looks for SlimServer out over the wireless interface.

The router sees the packets destined for SlimServer and retransmits them.


That is not what should happen at all. When the SB3 is operating in bridging mode, it keeps track of who is on the ethernet side and who is on the wireless side - it knows where to send a packet.

Telling it to connect wirelessly just means that you want to configure the wireless interface, but when bridging is enabled, both interfaces are "equal". In fact it is equivalent to a three-port ethernet switch. One interface is the ethernet port, one is the wireless port, and one is "virtually" connected to the SB3's IP stack.

So although that setup sounds convoluted, it really isn't... as far as the internal bridge is concerned, there is nothing unusual about it, and at the IP level none of it is even visible.

Mark Lanctot
2007-01-20, 12:56
That is not what should happen at all. When the SB3 is operating in bridging mode, it keeps track of who is on the ethernet side and who is on the wireless side - it knows where to send a packet.

Telling it to connect wirelessly just means that you want to configure the wireless interface, but when bridging is enabled, both interfaces are "equal". In fact it is equivalent to a three-port ethernet switch. One interface is the ethernet port, one is the wireless port, and one is "virtually" connected to the SB3's IP stack.

So although that setup sounds convoluted, it really isn't... as far as the internal bridge is concerned, there is nothing unusual about it, and at the IP level none of it is even visible.

Sean:

That is very cool. It would appear that the Squeezebox in bridged mode is a lot smarter than I thought!

I'll edit the wiki appropriately.

peter
2007-01-20, 13:30
Mark Lanctot wrote:
> seanadams;172362 Wrote:
>
>> That is not what should happen at all. When the SB3 is operating in
>> bridging mode, it keeps track of who is on the ethernet side and who is
>> on the wireless side - it knows where to send a packet.
>>
>> Telling it to connect wirelessly just means that you want to configure
>> the wireless interface, but when bridging is enabled, both interfaces
>> are "equal". In fact it is equivalent to a three-port ethernet switch.
>> One interface is the ethernet port, one is the wireless port, and one
>> is "virtually" connected to the SB3's IP stack.
>>
>> So although that setup sounds convoluted, it really isn't... as far as
>> the internal bridge is concerned, there is nothing unusual about it,
>> and at the IP level none of it is even visible.
>>
>
> Sean:
>
> That is very cool. It would appear that the Squeezebox in bridged mode
> is a lot smarter than I thought!
>

I hope you have now learned to never underestimate a SqueezeBox, Marc! ;)

Regards,
Peter

peter
2007-01-20, 13:33
seanadams wrote:
> Mark Lanctot;172337 Wrote:
>
>> I'm amazed this all works?
>>
>> Because this is a convoluted wireless arrangement. Say the SB3 wants
>> to send something to SlimServer. It can't do this over its crossover
>> cable because you've told it to use the wireless interface and bridge
>> the Ethernet port. So it looks for SlimServer out over the wireless
>> interface.
>>
>> The router sees the packets destined for SlimServer and retransmits
>> them.
>>
>>
>
> That is not what should happen at all. When the SB3 is operating in
> bridging mode, it keeps track of who is on the ethernet side and who is
> on the wireless side - it knows where to send a packet.
>
> Telling it to connect wirelessly just means that you want to configure
> the wireless interface, but when bridging is enabled, both interfaces
> are "equal". In fact it is equivalent to a three-port ethernet switch.
> One interface is the ethernet port, one is the wireless port, and one
> is "virtually" connected to the SB3's IP stack.
>
> So although that setup sounds convoluted, it really isn't... as far as
> the internal bridge is concerned, there is nothing unusual about it,
> and at the IP level none of it is even visible.
>

Sean, wouldn't that also imply that an SB running in bridge mode could
function as a poor man's access point by connecting to a wireless PC in
ad-hoc mode?

Regards,
Peter

Ramage
2007-01-20, 13:39
I did check my test setup with the wireless access point disabled and the NSLU slimserver continued to work with the SB3 over the wired xover cable. When the wireless link was restored, access from the PC to the NSLU was restored.

I was quite impressed by the functionality, confirmed by Sean.

Great piece of kit.

BTW this was just a test arrangement put together to answer Puggie's query at post #6, and not part of my permanent set-up.

But I may have to think of some way to use this added flexibility.

azinck3
2007-01-20, 13:54
Sean, wouldn't that also imply that an SB running in bridge mode could
function as a poor man's access point by connecting to a wireless PC in
ad-hoc mode?

Regards,
Peter

I think you're right, but that it would be quite an interesting poor man who has a squeezebox, computer, and internet access but not $30 for an access point!

Mark Lanctot
2007-01-20, 13:56
I hope you have now learned to never underestimate a SqueezeBox, Marc! ;)

Most definitely. What's interesting about this is that this is above and beyond what is required. The Squeezebox operating in bridge mode really doesn't need to check if there are any packets destined for itself (because 95% of the time, SlimServer will not be on the bridged side) but the fact that it does is wonderful!

This opens up whole new possibilities as I touched upon in the wiki now. With a NAS or quiet server in wired range of your Squeezebox and your router connected wirelessly, you get it all:

- very fast, reliable wired bandwidth for music playback and SlimServer access

- access to SqueezeNetwork over wireless, which should be fine as there aren't many/any high-bitrate streams

- access to SlimServer from the rest of your network, both wired and wireless portions

- the NAS/server will also have Internet access

About the only drawback to this arrangement is if you have another Squeezebox on the wireless portion because it'll be a 2-hop arrangement - which isn't a problem for some people though.

peter
2007-01-20, 14:44
azinck3 wrote:
> Peter;172381 Wrote:
>
>> Sean, wouldn't that also imply that an SB running in bridge mode could
>> function as a poor man's access point by connecting to a wireless PC in
>>
>> ad-hoc mode?
>>
>> Regards,
>> Peter
>>
>
> I think you're right, but that it would be quite an interesting poor
> man who has a squeezebox, computer, and internet access but not $30 for
> an access point!
>

Yeah, I realized that, but only after I pressed 'send' ;)

Regards,
Peter

azinck3
2007-01-20, 15:47
azinck3 wrote:
> Peter;172381 Wrote:
>
>> Sean, wouldn't that also imply that an SB running in bridge mode could
>> function as a poor man's access point by connecting to a wireless PC in
>>
>> ad-hoc mode?
>>
>> Regards,
>> Peter
>>
>
> I think you're right, but that it would be quite an interesting poor
> man who has a squeezebox, computer, and internet access but not $30 for
> an access point!
>

Yeah, I realized that, but only after I pressed 'send' ;)

Regards,
Peter

Oh, I didn't mean to be critical, just thought it funny. I have observed others around here doing things much less convoluted than that in the name of saving a few bucks!

seanadams
2007-01-20, 16:04
Sean, wouldn't that also imply that an SB running in bridge mode could
function as a poor man's access point by connecting to a wireless PC in
ad-hoc mode?

Yes it can. In fact you can even connect two Squeezeboxes to each other in ad-hoc mode with bridging enabled, and thereby bridge two ethernet LANs together.

The thing it can not do is to be a real access point with more than one 802.11 station connected.

peter
2007-01-21, 02:41
azinck3 wrote:
> Peter;172405 Wrote:
>
>> azinck3 wrote:
>>
>>> Peter;172381 Wrote:
>>>
>>>
>>>> Sean, wouldn't that also imply that an SB running in bridge mode
>>>>
>> could
>>
>>>> function as a poor man's access point by connecting to a wireless PC
>>>>
>> in
>>
>>>> ad-hoc mode?
>>>>
>>>> Regards,
>>>> Peter
>>>>
>>>>
>>> I think you're right, but that it would be quite an interesting poor
>>> man who has a squeezebox, computer, and internet access but not $30
>>>
>> for
>>
>>> an access point!
>>>
>>>
>> Yeah, I realized that, but only after I pressed 'send' ;)
>>
>> Regards,
>> Peter
>>
>
> Oh, I didn't mean to be critical, just thought it funny. I have
> observed others around here doing things much less convoluted than that
> in the name of saving a few bucks!
>

That's the way I interpreted it :)

Regards,
Peter

Puggie
2007-01-21, 09:30
sounds great guys, once I have re-read this thread a few times and absorbed the content properly I should know exactly what its capable of. For this project its more a case of I'll have a SB2 there and will occasionally need a wireless bridge so it would save both cash and equipment if the SB2 would act as my bridge to attach the computer to my LAN wirelessly. which it appears it will :)

And I feel slightly less stupid having asked the question as plenty of other members seem to have learnt something about the SB2/3s networking abilities :p

Eric Carroll
2007-01-24, 20:46
That is not what should happen at all. When the SB3 is operating in bridging mode, it keeps track of who is on the ethernet side and who is on the wireless side - it knows where to send a packet.


Sean,

If I may say as a guy who does IP networking for a living, building a bridge into the SB3 & Tp was a stroke of simple genius and a major differentiator in the product.

It really shows a seperation of the "audio" crowd from the audio as a network application thought process.

In one shot, I now have wired connectivity all over my house. No additional .11g interfaces, cards, WAPs, antennae, or anything.

I think the bridge function is tremendously underestimated in the market.

My only complaint: I wanted an integrated multiport switch! No pleasing some people... :-) Consider it as a possible different offering just like Linksys does (one port device, multiport integrated switch etc etc).

Good job and thanks.

Eric Carroll
2007-01-24, 21:05
About the only drawback to this arrangement is if you have another Squeezebox on the wireless portion because it'll be a 2-hop arrangement - which isn't a problem for some people though.

Mark,

Some points that I hope are not already clear but hopefully address a couple of points in your posting.

Bridges build topology of the layer 2 (Ethernet) network based on listening to the MAC address connected to each port (or if cycles exist in the network using spanning tree protocol). So each bridge knows what MACs are on which port, by definition of how bridges work. So don't worry about packets going wrong direction - bridges know where the MAC is (the exception is if a bridge gets a packet and has not heard the MAC previously, then it "floods" the packet to all bridge ports).

Also, ARP is running, so device IP stack ARPs the destination IP and get the MAC, before sending. When the device is "local" to the Ethernet (in the same subnet, wired or not - the contiguous bridged domain) the device stack knows not to use the router for packet forwarding. If a device is locally connected the packet goes direct.

Finally, hops don't matter. Don't let anyone tell you they do. Most people who think hop counts are important are listening to old anti-IP FUD from ATM and TDM vendors of years gone by and IP stacks with low initial TTL from yesteryear.

The simple fact is that the cut through time (time from first bit in to first bit out with no queueing delay) on a two port bridge (which is what the SB3 is) is measured in microseconds. If the silicon is less intelligent and buffers the whole packet, you are looking at milliseconds. It just doesn't matter.

If you were going multiple times over the same wireless network, that would be an issue, but that is not what is happening in this example.

Mark Lanctot
2007-01-24, 21:44
If you were going multiple times over the same wireless network, that would be an issue, but that is not what is happening in this example.

Hmm? I thought it was?

NAS (SlimServer) - SB (acting as bridge) to router, one wireless hop.

Router/AP to another SB, wireless, 2nd wireless hop.

There have been quite a few users on this forum who've had problems trying to do things like this, i.e. a wireless SlimServer connected to a wireless router connected to a wireless Squeezebox.

Eric Carroll
2007-01-24, 23:49
Hmm? I thought it was?

NAS (SlimServer) - SB (acting as bridge) to router, one wireless hop.

Router/AP to another SB, wireless, 2nd wireless hop.


Well, my bad, that will teach me to respond without reading more carefully, and I know better. Sorry.

"router" confused me. A wireless access point (WAP) can be either a bridge or a router. In my network my WAP is a bridge. The SB is a Wireless Station (STA), either end device or bridge.

So, let's take three cases.

1) Peer to Peer mode. Topology:

SlimServer - STA(SB,Bridge) - 802.11g - STA(SB)

2) Infrastructure mode. Topology:

SlimServer - STA(SB,Bridge) - 802.11g - WAP - 802.11g - STA(SB)

3) LAN topology:

Computer - STA(SB,Bridge) - 802.11g - WAP - 802.11g - STA(SB)
WAP - LAN - SlimServer

(1) there is no routed hops and 1 wireless "hop". Hops usually mean routers (decrement TTL and forward). If you are running 11g and have good wireless connectvity you should have no issues in this mode. STA(SB) sends request to SlimServer, it flows STA(SB) direct to STA(SB,Bridge). Then the bridge function looks at the packet, sees the MAC is for the Slimserver, looks at its MAC forwarding table and sees the SlimServer is on the wired port, and forwards it out the Ethernet wired port. The SlimServer responds, sends a packet to the STA(SB,Bridge), who looks at the MAC header, sees that it needs to go wireless and sends it to STA(SB).

In this case, you should get usual speed of 24 Mb/s or peak speeds of 54 Mb/s, well able to support a FLAC stream at .3-1 Mb/s plus headers.

(2) there is no routed hops if the WAP is a bridge. If the WAP is a router, and the packet is STA to STA *there is no routed hop* (meaning no TTL decrement, its on the same IP subnet). In this topology the WAP side of the router acts as a wireless bridge from an IP perspective. There are 2 wireless access network "hops". Path in this example is the STA(SB) sends to WAP, who retransmits to STA(SB,Bridge). STA(SB,Bridge) sees the MAC is for the SlimServer which is out the Ethernet interface, and forwards it. Reply from SlimServer goes to STA(SB,Bridge), forwards to WAP, forwards to STA(SB).

Since 11g has a peak bandwidth of 54 Mb/s and usual speed of 24 Mb/s, you should have no problem getting 10 Mb/s thoughput (half of the AP usual speed).

(3) There is one wireless "hop" from SlimServer to SB, the usual configuration.

So your example is (2), right? Given the forwarding outlined above, and a usual .11g speed of 24 Mb/s (peak speed of 54 Mb/s), and FLAC streaming at .3-1 Mb/s (plus header overhead) you should not have trouble supporting a FLAC stream from SlimServer to SB.

However, if you have marginal wireless connectivity or use 11b, data rates plunge massively and this will definately be a problem. This is likely the source of connectivity problems when using topology (2). Set the WAP to .11g mode only, and check wireless strength. If necessary, buy high gain antennae for the WAP to help.

Another point you made confused me too:


I'm amazed this all works?

Because this is a convoluted wireless arrangement. Say the SB3 wants to send something to SlimServer. It can't do this over its crossover cable because you've told it to use the wireless interface and bridge the Ethernet port. So it looks for SlimServer out over the wireless interface.


This is what I was really responding to. See my packet flow above - the Bridge determines which side the MAC address is on. All bridges necessarily recognize traffic for themselves, so its easy to have the SB be a virtual "interface" within the bridging function. Looking at the postings I see Sean answered that point.

I hope this fixes my reply and undoes any confusion...

oreillymj
2007-01-25, 03:37
Just going back to the orignal reason the poster asked this question, a car based Slimserver.

Has anyone got experience of runing a hard-drive continuously in a car.
I'd have thought the constant shocks would dramatically shorten the lifespan of a HD. The roads in this country vary from good motorway to tarmac'd donkey tracks. I'd imagine I'd get less than a week out of a HD before it started reporting errors.

From what I've heard the life span of iPOD HD's is about 2-3yrs and they have intelligent caching so that the HD spends most of it's time idle with songs playing back from RAM. The HD just spin's up to fill the cache and then shut's off.

Since Slimserver does not do this, it would need the OS on the NSLU to cache transparently.

peter
2007-01-25, 03:54
oreillymj wrote:
> Just going back to the orignal reason the poster asked this question, a
> car based Slimserver.
>
> Has anyone got experience of runing a hard-drive continuously in a
> car.
> I'd have thought the constant shocks would dramatically shorten the
> lifespan of a HD. The roads in this country vary from good motorway to
> tarmac'd donkey tracks. I'd imagine I'd get less than a week out of a
> HD before it started reporting errors.
>

I've been running an iRiver H140 in my car permanently for the last 3
years. It's been in there 24/7 on cold nights and hot days and it
survived speedbumps with no problems. Laptop drives are designed to
withstand this kind of thing. Desktop drives are ridiculously cheap so
you can easily afford to replace one if it should break. The data is
usually just a copy/selection of you main library so backups aren't an
issue. In practice this shouldn't be a problem.
> >From what I've heard the life span of iPOD HD's is about 2-3yrs and
> they have intelligent caching so that the HD spends most of it's time
> idle with songs playing back from RAM. The HD just spin's up to fill
> the cache and then shut's off.
>

iPods have the same drives as my iRiver. If you carry it around in your
pocket it will fall to the ground sometimes. My iRiver has bounced
across Amsterdam street on occasion to no ill effect. That would be much
worse than having it in a car, that's protected with shock absorbers and
crumple zones.

> Since Slimserver does not do this, it would need the OS on the NSLU to
> cache transparently.
>
I wouldn't worry about it.

Regards,
Peter

oreillymj
2007-01-25, 04:11
Strange, I'm on my 2nd hard drive in the laptop I've had for < 2yrs. And I consider myself careful. It spends most of it's life on my desk, in hibernation or fairly stable on my lap.

And the laptop has those sensors which detect movement and tell the drive to spin down.

The 2nd drive was installed in Oct-06 and I see errors in event log reporting bad sectors.

peter
2007-01-25, 05:02
oreillymj wrote:
> Strange, I'm on my 2nd hard drive in the laptop I've had for < 2yrs. And
> I consider my self careful. It spends most of it's life on my, in
> hibernation or fairly stable on my lap.
>
> And the laptop has those sensors which detect movement and tell the
> drive to spin down.
>
> The 2nd drive was installed in Oct-06 and I see errors in event log
> reporting bad sectors.
>

A certain percentage of hard drives fail anyway, even when installed in
servers or desktops. My own experience with laptops is pretty good. I
had one drive fail when it was almost new in 10 years or so. I'm on my
fourth laptop now, and I'll be getting the fifth real soon.

Regards,
Peter

seanadams
2007-01-25, 08:15
The simple fact is that the cut through time (time from first bit in to first bit out with no queueing delay) on a two port bridge (which is what the SB3 is) is measured in microseconds.

I think that could only be true of an hardware ethernet switch (in silicon), or some architecture where the controller/CPU has the ability to start putting an outgoing frame on the wire before it is fully received. Obviously having the destination MAC as the first thing in the frame header makes this possible.

However a software bridge or access point typically would store and forward, for a number of reasons - your first bit doesn't go back out until the last bit is in.

One thing that is interesting about the Ubicom platform we use is that they implement the ethernet MAC in software. So as a bridge, the implementation would be considered somewhere between a minimal-latency silicon implementation and a "software plus ordinary ethernet interfaces". The advantage it has is that a packet coming in on the ethernet port goes straight into memory as it comes off the wire, so the step of copying the packet from an external ethernet chip's RX buffer is eliminated. The OS does not do any copies internally, and of course the reverse is also true for the TX direction. This is probably faster than most access points, but not as fast a hardware ethernet switch.

So, while I'd rather have a 10-hop connection with 10ms latency than a 2-hop connection with 100ms latency, I wouldn't go as far as saying that hops don't matter... they don't matter much at very high interface speeds, but as you talk about slower link speeds the time for a packet to get in and out of the buffers becomes material.

Eric Carroll
2007-01-25, 08:59
One thing that is interesting about the Ubicom platform we use is that they implement the ethernet MAC in software.

I assumed you used a Ethernet MAC chipset, which are relatively cheap these days and can do hardware cut through, but software is even less expensive. This is an important point, thanks for the clarification.

So, let's calculate. Assuming the wireless is working at full data rate, 54 Mb/s, a maximum size Ethernet packet of 1500 bytes, serialization time is about .2 ms. Double that if you get only 24 Mb/s to .5 ms. x 2 for input & output is 1 ms (which is only true for wired Ethernet devices). If we assume .1 ms (20K instructions at 200 MHz?) to make the switching decision (I hope not, but let's say) you have about 1 ms rounded per wireless "hop" in .11g land.


The advantage it has is that a packet coming in on the ethernet port goes straight into memory as it comes off the wire, so the step of copying the packet from an external ethernet chip's RX buffer is eliminated.

As you probably know OS copying of packet buffers (and the corresponding handling of interrupts) is a major throughput rate limit of software based bridges and routers. So, based on the Ubicom optimization, you only take one serialization delay (since you are doing half-way cut through), and your expected device latency should be in the range of .6 ms per SB at 24 Mb/s .11g link speeds. Nice optimization from the Ubicom stack.

So, it doesn't matter... Lots and lots of "hops" before TCP even begins to notice the bandwidth delay product.

If we were dealing with 1 Mb/s connections, serialization delay is 12ms x 2 = 25 ms per hop or 12 ms with the Ubicom optimization. At 10s of ms per hop you have to start thinking about when to care - but you don't care yet. Still lots and lots of hops at 12ms before TCP notices.

Now if I set my way back clock and think about dial (now like a high end GSM cellular GPRS packet link)... serialization time of a 56kb/s is 200ms x 2 for 400ms per hop. Yep, this matters quickly: RTT is twice this, for 800ms. Now that's real delay!

seanadams
2007-01-25, 11:39
Since I happen to have a shielded RF test enclosure in front of me with an access point and a Squeezebox in it, here are the actual numbers. I have the computer wired directly to the squeezebox, and squeezebox connecting to the access point with bridging enabled.

First, ping the Squeezebox directly over ethernet:

# ping -f -c 10000 -q 10.1.1.10
PING 10.1.1.10 (10.1.1.10): 56 data bytes
--- 10.1.1.10 ping statistics ---
10000 packets transmitted, 10000 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.165/0.214/1.760/0.038 ms


Now ping the access point through the squeezebox:

# ping -f -c 10000 -q 10.1.1.2
PING 10.1.1.2 (10.1.1.2): 56 data bytes
--- 10.1.1.2 ping statistics ---
10000 packets transmitted, 10000 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.266/1.945/10.717/0.456 ms


And now with big packets to the squeezebox:

# ping -f -c 10000 -q -s 1460 10.1.1.10
PING 10.1.1.10 (10.1.1.10): 1460 data bytes
--- 10.1.1.10 ping statistics ---
10000 packets transmitted, 10000 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.410/0.525/1.950/0.045 ms


And to the access point:

# ping -f -c 10000 -q -s 1460 10.1.1.2
PING 10.1.1.2 (10.1.1.2): 1460 data bytes
--- 10.1.1.2 ping statistics ---
10000 packets transmitted, 10000 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.129/2.857/12.592/0.396 ms


And for good measure, the loopback:
(31% packet loss?!? this is on macos)

# ping -f -c 10000 -q -s 1460 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 1460 data bytes
--- 127.0.0.1 ping statistics ---
10000 packets transmitted, 6813 packets received, 31% packet loss
round-trip min/avg/max/stddev = 0.017/0.022/0.104/0.005 ms



Taking the averages and subtracting the loopback we get:

SB 56B: 192 us
AP 56B: 1923 us
SB 1400B: 503 us
AP 1400b: 2835 us

And now you can work out all sorts of things...

The difference in transmission time for 1400B vs 56B @ 100Mbps == (1400 - 56) * 8 * 10 ^ -8 == 108 us. Multiply by two for the rtt == 216 us.

503 - 192 - 216 == 95 us. That is the amount of extra work done somewhere, probably mostly on the computer's side for copying to/from the ethernet chip, to handle a large packet versus a small one. There is also some time spent verifying IP checksums on both sides.

The transmission time for 56 bytes (plus preamble and frame headers == 56 + 28 == 84 bytes) would be 84 * 8 * 10 ^ -8 == 7 us. So we can see that the 192 us ping time for a small packet is dominated by os and application overhead: 192 - 7*2 = 178 us

If we take the 95 us of overhead for response time difference between big packets and small packets through the ethernet link, and subtract that from the difference between big packets and small packets through the wireless+ethernet path, then we can work out the transmission speed of the wireless:

2835 - 1923 - 95 = 817 us. Divide by two since that's both directions == 409us. And to get the data rate: (1400-56)*8 bits per 409 us == 26.3 Mbps.

Now test this by doing a file transfer through the SB+AP to another computer (both directions):

# scp sadams@10.1.1.9:~/bigfile .
bigfile 100% 10MB 3.3MB/s 00:03

# scp bigfile sadams@10.1.1.9:~/bigfile
bigfile 100% 10MB 3.3MB/s 00:03

3.3*8 == 26.4 Mbps... nifty eh?

Eric Carroll
2007-01-25, 11:53
Very nifty! And I guessed 24 Mb/s with no measurement, no data and just a virtual napkin...

This is getting to be too much like work. :-) I think I will go listen to my Transporter :-)

bludragon
2007-02-09, 10:28
That is not what should happen at all. When the SB3 is operating in bridging mode, it keeps track of who is on the ethernet side and who is on the wireless side - it knows where to send a packet.

Telling it to connect wirelessly just means that you want to configure the wireless interface, but when bridging is enabled, both interfaces are "equal". In fact it is equivalent to a three-port ethernet switch. One interface is the ethernet port, one is the wireless port, and one is "virtually" connected to the SB3's IP stack.

So although that setup sounds convoluted, it really isn't... as far as the internal bridge is concerned, there is nothing unusual about it, and at the IP level none of it is even visible.


I enabled bridging last night, with the hope of creating the following network:

wireless internet gateway/router <-- wireless --> sb2 <-- wire --> hub <-- wire --> slimserver

Both the sb and server were set to use DHCP, with the router supplying ip addresses etc. Squeezebox connected to the network ok, and could connect to squeezenetwork, but not my own server. Meanwhile my server did not get DHCP. Setting it's ip manually (to use the router as a gateway) meant it could ping the squeezebox, but not access the internet, or be accessed by the squeezebox. I'm using slimserver 6.5.1 with matching firmware

At that point I gave up thinking this type of scenario simply hadn't been tested, but that the solution would be exactly what Sean has described above.

Having now read Sean's post, I'm keen to hear any ideas as to where I might have gone wrong?

One thing I just though of, is do the pc's on the wired portion of the network need to treat the squeezebox as the gateway, rather than the wireless router - means none of them can have dhcp, but that shouldn't be a huge issue - will try this tonight...

bludragon
2007-02-09, 14:27
ok, it officially doesn't work for me :-(

Ramage
2007-02-10, 05:07
Just to test the feasibility of your proposal I set up the following:

* NSLU NAS+Slimserver connected to SB3 with crossover ethernet cable
* Set up wireless bridge to my main network.

Entered all required IP addresses for my network and it worked perfectly.

I am able to connect the SB directly to the Slimserver on the NSLU through the cable and also access the NSLU from my PC over the wireless bridge, as if it was connected directly to the network. The NSLU is also able to access the internet through the default gateway.

Looks like what you propose will work OK

My test setup worked OK; however I was using SS v6.3.1 and SB3 FW version 55.

I tried the same setup today but with SS 5.6.2 FW 72 and the wireless bridge did not work. Looks like the FW update may have broken it.

Ramage
2007-02-11, 04:09
My test setup worked OK; however I was using SS v6.3.1 and SB3 FW version 55.

I tried the same setup today but with SS 5.6.2 FW 72 and the wireless bridge did not work. Looks like the FW update may have broken it.

Tested my setup today after downgrading the SB to FW v55, and it worked as you might expect it to, and as explained by Sean in a previous post on this thread.

Conclude that the FW v72 has broken the wireless bridge, (I have no means of testing FW builds in-between).

Ramage
2007-02-11, 05:18
Leaving my wireless bridge set-up in place, I upgraded the SB3 to FW 72.

On restart, the bridge worked as expected. BTW upgrading to FW72 does not require the connection to be set up from scratch, so that the bridge settings were left in place from FW55.

The problem seems to be that FW72 does not allow a bridge to be set up properly.

bludragon
2007-02-11, 05:44
Thanks Ramage,
If I get a chance later today I will try to revert to fw v55 to see if it works.

seanadams
2007-02-11, 21:35
In the test I did recently, bridging in FW72 worked fine _except_ in Ad-hoc mode. No problems bridging to a Linksys AP.

If we're all seeing the same thing then we should open a bug.

Ramage
2007-02-12, 02:20
Leaving my wireless bridge set-up in place, I upgraded the SB3 to FW 72.

On restart, the bridge worked as expected. BTW upgrading to FW72 does not require the connection to be set up from scratch, so that the bridge settings were left in place from FW55.

The problem seems to be that FW72 does not allow a bridge to be set up properly.

Sean

I am unable to replicate the previous failure with FW 72 at present and I haven't tried an ad-hoc connection. Maybe the full reset by switching to FW55 and back to FW72 cleared the problem - or maybe it was operator error ;-)!

Perhaps Bludragon can report how he got on.

Edit: Did a full factory reset with FW 72, set up the wireless bridge and it worked as expected.

bludragon
2007-02-12, 04:12
I'm not using ad-hoc mode either. I tried downgrading to the firmware with slimserver 6.5.0 (FW 65 I think), turned bridging off, then back on, and it didn't work, then FW 55 (6.3.1), and it still didn't work. When going back to FW 55 I needed to re-enter the WPA key.

I didn't have much time to play with it, but the symptoms were the same in all cases - if I set the ip of the wired server manually, I can ping the squeezebox, but nothing on the wireless network, and the squeezebox cannot connect to the server.

Will try a factory reset tonight and let you know what happens.

Ramage
2007-02-12, 06:25
My set-up is:

NSLU2> SB3> Wireless (Netgear DG834, 128bit WEP)> PC1 (WinXP), PC2 (Linux).

I can ping all the units on the network and can access Slimserver running on any of the network PCs and NSLU2 which is also a NAS from the SB3.

I am using DHCP but each network device has a preallocated IP. I can connect and disconnect the NSLU2 and the bridged link recovers when reconnected.

Similarly, if I disable the WAP access, the SB3 remains connected to the wired NSLU Slimserver.

bludragon
2007-02-12, 13:07
OK, well, I've come to the conclusion that this just isn't going to work for me. With fw55 I tried a factory reset, WEP instead of WPA, unplugging everything and plugging it all back in again, but still didn't get it working.

Maybe the netgear hub between the sb and my server is confusing things, but I don't have a crossover cable to test without that in the way.

bludragon
2007-02-12, 13:35
Found a cable, took the hub out of the loop, and now it works.

btw, if I ever have to type a full length randomly generated WPA key in again using the sb remote I think I might just go nuts... Any change of putting network settings in the web interface (with appropriate WARNING for the foolish)?

Mark Lanctot
2007-02-12, 14:27
btw, if I ever have to type a full length randomly generated WPA key in again using the sb remote I think I might just go nuts... Any change of putting network settings in the web interface (with appropriate WARNING for the foolish)?

...how would that work? The player hasn't connected to the network yet, how can SlimServer push the data to it?

I agree, entering in a passphrase is a pain, but I can't think of any alternatives.

bludragon
2007-02-13, 01:59
...how would that work? The player hasn't connected to the network yet, how can SlimServer push the data to it?

I agree, entering in a passphrase is a pain, but I can't think of any alternatives.

You could only change things once the sb was on the network, but that could easily be achieved via either a temporary ethernet cable, or a temporary wireless security setup. Once connected, you can then change the wireless settings via the web interface as often as you like, as long as you first change them on the sb, then on the wireless ap.

oreillymj
2007-02-13, 04:28
I remember having a problem with a Netgear wireless bridge I bought for linking my PS2 to my network.

The bridge couldn't connect to the network initially with WEP enabled, but if I disabled WEP it worked, then set it to 64bit WEP, and still worked, then 128bit still worked.

I just figured that it was something to do with settings corruption. Reported it to both Netgear & Belkin, but go no answer from either.

With a few wireless components around the house, it's a pain to visit each one changing channels, keys etc.. when testing these sort of issues.

I was lucky enough to be able to run with WEP disabled until about 6 months ago when I found the neighbours sponging off my connection.

bludragon
2007-02-14, 07:27
So the last thing I tried was to power the router on last, but that didn't help. Does anyone know why the router might be breaking the 'bridging' of the sb? I would have thought it should be completely passive. I can't really use this configuration without a router, or a switch in place - not sure if a different router, or a switch instead would work.

Thanks

hau
2008-01-24, 09:53
When the SB3 is operating in bridging mode, it keeps track of who is on the ethernet side and who is on the wireless side - it knows where to send a packet.


What happens when it doesn't know who's on which side?

Reason I'm asking this, is that I'm trying to use WOL to wake up my living room PC from internet (using e.g. dslreports.com's wakeup service http://www.dslreports.com/wakeup).

If I send a WOL magic packet from my local net it of course spreads via WLAN to SB3 and, as it is a broadcast packet, SB3 forwards it to the ethernet port and the PC wakes up.

When I'm using the dslreports' 'service' the packet comes to my network as a _unicast_ packet. I have configured my ADSL-modem/router with static ARP for the PC, and a rule to forward UDP port 9 packets to the PC's IP address.

When I've connected the PC to one of the ADSL-modem/router's ethernet ports send the packet from internet, my PC wakes up.

When I place the PC on SB3's ethernet port and send the packet from the same site the PC stays powered off.

In my understanding there might be two reasons for this.
- Either the ADSL device forgets to forward the packet to WLAN along with all the ethernet ports, or
- SB3 drops the packet as it doesn't know that the addressee is on its ethernet port.

After some email exchange with the tech guys from modem manufacturer, they assure me that all packets that are distributed to the ethernet ports will also be sent to WLAN. If this is the case, then the SB3 drops the packet and I'd like to know whether it would be possible to change the behavior of SB3's IP stack in such a way, that if it doesn't know (no entry in ARP table?) the recipients 'location' on the net, it would forward the packet?

Best regards,
Mika

seanadams
2008-01-24, 11:45
What happens when it doesn't know who's on which side?


The WOL packet is a broadcast so it shouldn't matter, but to answer your question I believe if it doesn't know it will behave like a hub and send it to all ports.

hau
2008-01-24, 12:45
The WOL packet is a broadcast so it shouldn't matter, but to answer your question I believe if it doesn't know it will behave like a hub and send it to all ports.

The problem is that the packet which is sent from the internet is otherwise structured as a WOL packet, but in fact is a UDP packet sent to a certain address (unicast). (My ADSL router then forwards it internally to the specified address.)

I have now used windump (tcpdump) and found out that the packet actually comes to my net and is destined to the right IP. I hope to find a PC with wireless card for the weekend to check that the packet is also sent over the air. Then, I think, it is easier to track down the problem.

Cheers,
Mika

seanadams
2008-01-24, 20:14
The problem is that the packet which is sent from the internet is otherwise structured as a WOL packet, but in fact is a UDP packet sent to a certain address (unicast). (My ADSL router then forwards it internally to the specified address.)


Hmm. So here's an idea: try making that static ARP entry point to the broadcast MAC: "FF:FF:FF:FF:FF:FF".

This is a very strange and generally inadviseable thing as if it works, it will let someone on the internet create broadcast traffic on your LAN. However it would be an interesting test to do, although it is possible that your router will (justifiably) refuse to send the packet to the broadcast MAC via a static ARP entry. However if it works then maybe firewalling that port to only allow your remote IP to reach it would be acceptable to you.

Another thing to try would be to use a port redirect to send it to the broadcast IP, usually X.X.X.255.

hau
2008-01-25, 07:50
Hmm. So here's an idea: try making that static ARP entry point to the broadcast MAC: "FF:FF:FF:FF:FF:FF".

This is a very strange and generally inadviseable thing as if it works, it will let someone on the internet create broadcast traffic on your LAN. However it would be an interesting test to do, although it is possible that your router will (justifiably) refuse to send the packet to the broadcast MAC via a static ARP entry. However if it works then maybe firewalling that port to only allow your remote IP to reach it would be acceptable to you.


The idea was more than interesting to test, it also worked. Thank you very much!

I will have to go thru of course the security issues. (Security by obscurity might not be enough...) The firewall allows me to restrict outside connections to my LAN, so that shouldn't be a problem.



Another thing to try would be to use a port redirect to send it to the broadcast IP, usually X.X.X.255.

That was my first idea, but (not surprisingly) the router configuration interface didn't allow that.

Best regards,
Mika

seanadams
2008-01-25, 10:45
I am looking at our bridging implementation, and it is designed to forward to all ports in the event of a unicast packet whose MAC is not in its table. It is not clear to me if this is our problem or if something else is going on, so I am hesitant to open a bug without knowing any specifics.

It would be helpful to know whether the access point is actually sending the packet out to the wireless lan in the first place. To test that, put a wireless PC on it and run ethereal. I am not sure but I think you can monitor unicast traffic to other hosts that way without any special setup - you probably would need to disable encryption.

hau
2008-01-27, 07:57
I am looking at our bridging implementation, and it is designed to forward to all ports in the event of a unicast packet whose MAC is not in its table. It is not clear to me if this is our problem or if something else is going on, so I am hesitant to open a bug without knowing any specifics.

It would be helpful to know whether the access point is actually sending the packet out to the wireless lan in the first place. To test that, put a wireless PC on it and run ethereal. I am not sure but I think you can monitor unicast traffic to other hosts that way without any special setup - you probably would need to disable encryption.

I was so happy getting the thing to work, that I thought of not doing any further investigations. But, as you seem to be concerned, I took my laptop and started testing.

Based on my non-scientific approach, it seems that the access point (ADSL-modem w/ WLAN) is the one to blame! So, I'd say that there is no need dig further on SB3's bridging implementation.

As I had windump already installed, I used it on two machines, other being on the LAN and the other on WLAN. On ADSL modem I had two IP addresses with static ARP, the other with the real one and the other with MAC broadcast. Then I changed several times the IP address where the modem should forward the WOL-packet coming from dslreports.com. Not a single packet appeared on the WLAN with the real MAC address, but when I changed the address to the broadcast MAC, they were nicely printed out on the screen of the laptop on WLAN. All packets of course were received by the PC on LAN.

I will make a note for the tech guys at ADSL modem manufacturer.

Best regards,
Mika

dloose
2008-04-24, 13:10
I'm just curious -
If maximum bandwidth of .11g is 54 Mb/s and typical throughput is about 19 Mb/s, why does the SB v3 seem to top out at 3-5 Mb/sec (at least using the built-in test plug-in)? I'm using the SB in bridge mode to a Denon 3808CI and get not-infrequent drop-outs.

radish
2008-04-24, 13:22
I'm just curious -
If maximum bandwidth of .11g is 54 Mb/s and typical throughput is about 19 Mb/s, why does the SB v3 seem to top out at 3-5 Mb/sec (at least using the built-in test plug-in)? I'm using the SB in bridge mode to a Denon 3808CI and get not-infrequent drop-outs.

Mine doesn't. I find the SB3 to be a remarkably good (meaning fast & reliable) bridge - I've got 20mb/s through it in the past. My guess is that your signal strength isn't great or the network is congested due to other traffic.

Mark Lanctot
2008-04-24, 13:29
why does the SB v3 seem to top out at 3-5 Mb/sec (at least using the built-in test plug-in)?

It doesn't, that's just the network test plugin's maximum. Streaming audio files, you'll never need to go higher than about 5 Mbps, which would be 24/96 WAV (4608 kbps).