Bug 3660 - DHCP bridging does not work sometimes
: DHCP bridging does not work sometimes
Status: RESOLVED FIXED
Product: SB 2/3
Classification: Unclassified
Component: Wireless
: 55
: Linkstation Debian Linux
: P2 major with 1 vote (vote)
: ---
Assigned To: Richard Titmuss
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-29 12:35 UTC by Oscar Forsstrom
Modified: 2008-12-18 11:40 UTC (History)
6 users (show)

See Also:
Category: ---


Attachments
DHCP successful, w/ bridging turned off. (1.50 KB, application/octet-stream)
2006-08-24 11:12 UTC, Ross Levine
Details
failing, with bridging enabled. (4.11 KB, application/octet-stream)
2006-08-24 11:12 UTC, Ross Levine
Details
Log from Ethereal with WPA2 turned on (5.66 KB, application/octet-stream)
2006-09-10 09:12 UTC, Oscar Forsstrom
Details
Log from Ethereal without WPA2 (2.96 KB, application/octet-stream)
2006-09-10 09:13 UTC, Oscar Forsstrom
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oscar Forsstrom 2006-06-29 12:35:19 UTC
Went from firmware 30-somethinh to 55 to get WPA2 with AES to work. The SB2 now correctly gets connected to the access point and is assigned an IP-address, but stuff connected to the ethernet port doesn't get assigned an IP-address by DHCP. If I manually assign them an IP-address, everthing works.
Comment 1 Chris Owens 2006-07-25 15:26:18 UTC
Sorry for the delay.  

I can't seem to reproduce this currently.  Are you still experiencing this problem with FW58?
Comment 2 Oscar Forsstrom 2006-07-26 11:09:01 UTC
Yes, unfortunatly even firmware 59 gives the same result.
Comment 3 Chris Owens 2006-07-26 11:15:59 UTC
What kind of router or access point are you using?
Comment 4 Oscar Forsstrom 2006-07-26 12:07:16 UTC
I'm using a firewall based on pfsense with a WLAN-card from Atheros. Quite a special setup I must say. When rnning with my old setup (a netgear AP with WPA1, connected to the same pfsense firewall) everything works fine.
Comment 5 Chris Owens 2006-07-26 12:15:17 UTC
I assume that you've checked that you're not doing anything silly like blocking the ports DHCP uses (67 tcp and udp and 68 tcp and udp) from that connection?  :)

Does the new setup work if you set it for no encryption, do you know?

Since it's a special setup, I don't suppose you can monitor the DHCP traffic in some way to help us out here? :)
Comment 6 Oscar Forsstrom 2006-07-26 12:45:21 UTC
1) No blocking on any LAN-ports. Also see no 2.
2) Yes, without encryption everything works as expected.
3) Let me see. I havn't done it before, but I will google around and have a look...
Comment 7 Chris Owens 2006-08-19 16:43:26 UTC
It looks like there may be one or two other users having this problem, and they may all be using PCs with network cards rather than traditional wireless APs or routers.  I don't usually test with that arrangement, so perhaps I should set up a pfsense (http://www.pfsense.com/) system to have a look.  In the mean time, a log would be a valuable help.

Oscar, just to verify, the behavior you are seeing is that when the SB3 says it's acquiring a DHCP address, the countdown timer just runs out, and it offers to self-assign an address?  There's not any kind of error or unusual behavior that occurs?

Comment 8 Ross Levine 2006-08-23 13:03:45 UTC
Another customer of ours is seeing this bug. 

SB3 with firmware 55, Linksys WRT54G using WPA-PSK with DHCP disabled. He's running a Ubuntu server with DHCP. 

"Running ethereal on the dhcp server machine, I see the the DHCP
requests and responses.  It appears that the squeezebox just isn't
receiving them anymore." 

TMID 7849. 
Comment 9 Chris Owens 2006-08-23 13:08:49 UTC
Ross, so your user also doesn't have a normal access point, but is using a wireless card in a PC as their "wireless router"?  Or does he have a wireless router, but its internal DHCP server is disabled and he's using the one on his Ubuntu box?
Comment 10 Ross Levine 2006-08-23 13:12:07 UTC
Chris,

The latter is correct. He's using a Linksys WRT54G with DHCP disabled, and his Ubuntu server is acting as the DHCP server. 
Comment 11 Chris Owens 2006-08-23 13:30:34 UTC
Is it possible you could get an ethereal log from him to attach to the bug?
Comment 12 Ross Levine 2006-08-24 11:12:02 UTC
Created attachment 1472 [details]
DHCP successful, w/ bridging turned off.
Comment 13 Ross Levine 2006-08-24 11:12:35 UTC
Created attachment 1473 [details]
failing, with bridging enabled.
Comment 14 Ross Levine 2006-08-29 17:02:31 UTC
Richard, were you able to see anything interesting in these ethereal logs?
Comment 15 Chris Owens 2006-08-29 17:08:58 UTC
that last inquiry was from me, while I was sitting at Ross's computer.  Sorry for any confusion.
Comment 16 Oscar Forsstrom 2006-08-31 10:24:10 UTC
Sorry for not answering quicker. My @spymac address got cancelled. But now I am back!

An answer to #7 below: The countdown runs down to zero with no IP-address being aquired.

Comment 17 Oscar Forsstrom 2006-08-31 13:25:45 UTC
Hi again! I don't really agree with the new headline for this bug. I get the DHCP to work with bridging turned on when NOT using WPA. SO some mention of WPA should be in the headline...
Comment 18 Erik Hendriks 2006-08-31 14:05:18 UTC
I disagree with the headline for this bug as well.  I see the problem w/o a network-card-based access point.  I'm  using a Linksys WRT54G access point.  (See comment #8)
Comment 19 Chris Owens 2006-08-31 18:02:41 UTC
Seems to mostly affect network-card-based access points.

Does everyone agree it only happens on WPA?  Or is that also a variable?
Comment 20 Richard Titmuss 2006-09-01 02:26:05 UTC
I have been looking at this today, and would like to clarify a couple of points.

In the original comment I am correct it saying that DHCP on the Squeezebox works, but the it is DHCP on the bridged device that is failing. And is this correct for other people reporting this bug?

I may have found a problem during setup where the bridging option is not correct set until the Squeezebox is re-booted. Can you please try configuration the Squeezebox with Bridging enabled and WPA until it connects to the Slimserver. Then power cycle the Squeezebox, allowing it to automatically connect to the Slimserver. Can the bridged device now use DHCP and work correctly?

Richard

Comment 21 Erik Hendriks 2006-09-01 09:41:07 UTC
My configuration:
SB3 with firmware 55
Linksys WRT54G using WPA-PSK with DHCP disabled
DHCP server is an Ubuntu machine.

My experience was that DHCP failed for both the squeezebox AND the devices on the wired side of the squeezebox.

I'll try the reboot this evening.

Comment 22 Oscar Forsstrom 2006-09-01 11:29:27 UTC
My experience is that with firmware 55 both SB2 and bridged unit failed DHCP. With firmware 58 (59?) only the attached device failed. My installation is broken right now, but I'll try to reinstall ASAP and try the reboot.
Comment 23 Chris Owens 2006-09-01 11:30:53 UTC
Hm! I notice at least one person on the forums noting that firmware 60 (which is now in the nightlies) solved his DHCP problem which sounded like it might be similar to some of these.
Comment 24 Richard Titmuss 2006-09-04 15:01:57 UTC
It would be good to get some feedback if rebooting after completing setup helps this problem. I am planning to make a release candidate squeezebox2/3 firmware for 6.5 over the next couple of days and would like to get a fix in for this bug if possible.

Richard
Comment 25 Steve Kennedy 2006-09-04 15:57:47 UTC
I'm using an SB2 (firmware 55) going over air to a Netscreen 5GT ADSL/wireless.

WPA PSK is used and using private address space (DHCP by Netscreen).

Works fine if Ethernet bridging is disabled.

When Ethernet bridging is enabled it is able to connect to Netscreen and then times out trying to get an IP address.

There is another device plugged into the Ethernet port (also trying DHCP which also fails). Using a cross-over cable to connect the two.

Comment 26 Oscar Forsstrom 2006-09-04 21:38:36 UTC
I'm not able to try anything until the debian package is fixed. I read that Dan is on vacation and it will be fixed when he gets back...
Comment 27 Richard Titmuss 2006-09-06 06:34:40 UTC
I have fixed a bug releated to bridging during setup, the fix will be in firwmare sb62/t13. If the squeezebox was already configured, and you changed only the bridging option during setup then the change would not have any effect until the squeezebox was rebooted. This seems to be the only bug I have been able to find with bridging, tested with Linksys WRT54GS router and laptop configured to use dhcp.

Firmware sb62/t13 is currently undergoing internal testing. You will be notified again when it is made part of a nightly release. If after upgrading to the new firmware you are still having problems please re-open the bug.
Comment 28 Oscar Forsstrom 2006-09-10 09:12:58 UTC
Created attachment 1504 [details]
Log from Ethereal with WPA2 turned on
Comment 29 Oscar Forsstrom 2006-09-10 09:13:43 UTC
Created attachment 1505 [details]
Log from Ethereal without WPA2
Comment 30 Oscar Forsstrom 2006-09-10 09:36:42 UTC
I'm sorry to reopne the bug, but it still doesn't work for me. I have upgraded to firmware 62 and the bridged device still doesn't receive an IP address when WPA2 is turned on. I have attached Ethereal logs from both cases. I have also tried to powercycle the SB2. After the restart the SB2 refuses to receive an IP...
Comment 31 Richard Titmuss 2006-09-10 12:57:06 UTC
Oscar, I will look at the ethereal captures tomorrow. On what box did you perform the capture?  I really need to be able to recreate this bug in order to work out what's going wrong here. Can you please let me know/confirm:

- What device are you connecting to the bridge?
- What access point are you using?
- What is allocating the dhcp address?

You also mentioned that it works when using a netgear AP, is it possible that your access point is preventing the dhcp address being allocated?

Richard
Comment 32 Oscar Forsstrom 2006-09-10 14:07:25 UTC
My God, you ARE working day and night! ;-)

1. The device attached is my primary computer with an Abit motherboard with built in network i/f. This is connecyed to a Netgear gigabit switch which is connected to the SB2.

2. The access point is a PFsense firewall with a Wistron wifi-card (CM-9)

3. See 1, I think...

Yes, it is working with the Netgear AP, but only when using WPA1. That access point is rather old and only capable of WPA1.

The capturing was made with the primary computer. I havn't got any other computer capable of capturing the traffic. My Macbook Pro refuses to run Ethereal and I havn't been able to compile it for my Debian server...
Comment 33 Richard Titmuss 2006-09-10 14:31:55 UTC
So this is your network setup?

   --------     --------------
   |  PC  | --- | Gig Switch |
   --------     --------------
                      |
                      |
                --------------           -----------
                | Squeezebox |  --WLAN-- | PFsense | --- Internet
                --------------           -----------


If I understand correctly in your last reply you said the dhcp server is running on the PC, connected to the squeezebox on the ethernet port? Or do you mean the dhcp server is on the PFsense firmwall?
Comment 34 Oscar Forsstrom 2006-09-10 15:03:15 UTC
Yes, that is my setup (commenting the picture).

No, the DHCP runs on the pfsense firewall.
Comment 35 Richard Titmuss 2006-09-13 01:43:50 UTC
I am not going to have time to fix this for 6.5, retargetting for 7.0.
Comment 36 Richard Titmuss 2006-12-12 02:53:32 UTC
*** Bug 4557 has been marked as a duplicate of this bug. ***
Comment 37 Richard Titmuss 2006-12-12 02:56:21 UTC
Further investigation shows that bridging does not work correctly when WPA or WPA2 encryption is used. An extra 4 bytes of data are added to each ethernet packet sent on the bridged interface. This can also cause some packets to be dropped if the exceed the MTU.

This bug is fixed in firmware SB 71/TR 26. It is currently undergoing internal testing. You will be notified again when it is made part of a nightly release.
Comment 38 Richard Titmuss 2006-12-20 01:51:55 UTC
This bug fix will be available in tonight's nightly Slimserver
release. The release will be available from:

http://www.slimdevices.com/dev_nightly.html

at around 1:30 AM (Pacific Daylight Time) tomorrow morning. (08:30
UTC).

You'll need to install the new version of Slimserver, and then
force your Squeezebox upgrade its firmware by holding down the
"Brightness" button on the remote control until the firmware upgrade
process begins.

If you are still experiencing this problem after upgrading your
affected players to the new firmware, please reopen the bug.