rt73usb-add-bluenext-148f-2573

PATCH In review warmcat 2 participants 15 messages Jul 31, 2007 – Aug 1, 2007 Networking drivers (wireless)

lore

Share & tools

lore

warmcat

author

2007-07-31 11:54 UTC #0 lore raw

PATCH 1/1 rt73usb-add-bluenext-148f-2573

Add device ID for cheapo BlueNext rt2571-based stick BN-WD54G

Signed-off-by Andy Green <[email protected]>

---

 drivers/net/wireless/rt73usb.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

drivers/net/wireless/rt73usb.c +2 -0

index 3d838d1..82bb23c 100644
@@ -1814,6 +1814,8 @@ static struct usb_device_id rt73usb_device_table[] = {
 	{ USB_DEVICE(0x050d, 0x905b), USB_DEVICE_DATA(&rt73usb_ops) },
 	/* Billionton */
 	{ USB_DEVICE(0x1631, 0xc019), USB_DEVICE_DATA(&rt73usb_ops) },
+	/* BlueNEXT */
+	{ USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },
 	/* CNet */
 	{ USB_DEVICE(0x1371, 0x9022), USB_DEVICE_DATA(&rt73usb_ops) },
 	{ USB_DEVICE(0x1371, 0x9032), USB_DEVICE_DATA(&rt73usb_ops) },

Andy Green

author

2007-07-31 12:19 UTC #2 lore raw

Quoted 7 lines · Somebody in the thread at some point

drivers/net/wireless/rt73usb.c static struct usb_device_id rt73usb_device_table[] = { · line 1818
Quoted 2 lines
drivers/net/wireless/rt73usb.c +2 -0
+	/* BlueNEXT */
+	{ USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },
This USB ID is already in the List under the Label "Ralink"
	/* Ralink */
	{ USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },

Gah! I guess I jumped to the wrong conclusion when it didn't work, because rt2500usb.ko also claims this ID. Blacklisting rt2500usb and "adding" the ID in rt73usb got me able to do monitor mode, but I guess blacklisting rt2500usb was what did the trick.

Sorry for the noise, but maybe the same ID in rt2500usb should be removed, unless there is some story here about ID reuse...

-Andy

Ivo van Doorn

2007-07-31 12:24 UTC #3 lore raw

Quoted 7 lines · Andy Green

Quoted 5 lines · Somebody in the thread at some point
drivers/net/wireless/rt73usb.c static struct usb_device_id rt73usb_device_table[] = { · line 1818
Quoted 2 lines
drivers/net/wireless/rt73usb.c +2 -0
+	/* BlueNEXT */
+	{ USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },
This USB ID is already in the List under the Label "Ralink"

Quoted 7 lines

Quoted 2 lines
	/* Ralink */
	{ USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },
Gah! I guess I jumped to the wrong conclusion when it didn't work, because rt2500usb.ko also claims this ID. Blacklisting rt2500usb and "adding" the ID in rt73usb got me able to do monitor mode, but I guess blacklisting rt2500usb was what did the trick.

Quoted 2 lines

Sorry for the noise, but maybe the same ID in rt2500usb should be removed, unless there is some story here about ID reuse...

Unfortunately there have been reports about devices with that USB ID that contains a rt2500usb chipset. There are a number of duplicate USB ID's between rt2500usb and rt73usb.
Some manufacturers like to release new revisions of their wireless USB stick with different chipsets but with the same USB ID.

Ivo

Andy Green

author

2007-07-31 12:38 UTC #4 lore raw

Quoted 5 lines · Somebody in the thread at some point

Unfortunately there have been reports about devices with that USB ID that contains a rt2500usb chipset. There are a number of duplicate USB ID's between rt2500usb and rt73usb.
Some manufacturers like to release new revisions of their wireless USB stick with different chipsets but with the same USB ID.

Oh well.

Are there known problems with the monitor mode? It seems incomplete even with one virtual interface, eg

13:37:00.549494 1.0 Mb/s 2437 MHz (0x0480) 192dB signal Probe Request () [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
13:37:00.550243 1.0 Mb/s 2437 MHz (0x0480) 192dB signal Probe Request () [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
13:37:00.590127 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY 13:37:00.692568 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY 13:37:00.897401 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY 13:37:00.999773 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY

and reports the rate as 1Mbps in all cases. During this capture I have another box doing

# while [ 1 ] ; do ls -l / ; done

over an ssh link which is being carried on another wireless device on the same box associated on to channel 6...

-Andy

Ivo van Doorn

2007-07-31 12:54 UTC #5 lore raw

Quoted 2 lines

Are there known problems with the monitor mode? It seems incomplete even with one virtual interface, eg

Sounds awfully familiar. :(

Quoted 13 lines

13:37:00.549494 1.0 Mb/s 2437 MHz (0x0480) 192dB signal Probe Request () [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
13:37:00.550243 1.0 Mb/s 2437 MHz (0x0480) 192dB signal Probe Request () [1.0 2.0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit]
13:37:00.590127 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY 13:37:00.692568 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY 13:37:00.897401 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY 13:37:00.999773 1.0 Mb/s 2437 MHz (0x0480) 216dB signal Beacon (froh) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY

Quoted 2 lines

and reports the rate as 1Mbps in all cases. During this capture I have another box doing

At which rate should the other box be sending the frames?

Quoted 4 lines

# while [ 1 ] ; do ls -l / ; done
over an ssh link which is being carried on another wireless device on the same box associated on to channel 6...

Could you enable debugfs and do inside the "rt73usb" folder within the mac80211 debugfs entry do:

echo 16 > csr_offset
cat csr_value

This will read the TXRX_CSR0 register of rt73usb which controls the filtering of the frames. That will help determining if the missing frames have been droppen in the hardware or not.

Ivo

Andy Green

author

2007-07-31 13:35 UTC #6 lore raw

Quoted 4 lines · Somebody in the thread at some point

Quoted 2 lines
Are there known problems with the monitor mode? It seems incomplete even with one virtual interface, eg
Sounds awfully familiar. :(

Don't feel bad, monitor mode is not in a coherent state all over the drivers at the moment. I would really like to see it become trustable in all cases.

Quoted 1 line

At which rate should the other box be sending the frames?

54Mbps, I am a couple of metres from the AP.

Quoted 8 lines

Quoted 4 lines
# while [ 1 ] ; do ls -l / ; done
over an ssh link which is being carried on another wireless device on the same box associated on to channel 6...
Could you enable debugfs and do inside the "rt73usb" folder within the mac80211 debugfs entry do:

Quoted 6 lines

echo 16 > csr_offset
cat csr_value
This will read the TXRX_CSR0 register of rt73usb which controls the filtering of the frames. That will help determining if the missing frames have been droppen in the hardware or not.

I have to add debugfs in my .config for that, it is rebuilding.

However, I added the following debug line inside the loop at rt2x00_dev.c function
void rt2x00lib_rxdone(struct data_entry *entry, char *data,

	const int size, const int signal, const int rssi, const int ofdm)

		printk("signal=%d, ofdm=%d, rate->val=%d, val=%d\n", signal, ofdm,

rate->val, val);

and ran tcpdump at the same time. What I see is that even though tcpdump on ch 6 is only willing to show 1Mbps packets, packets with other rates passed through here, eg,

signal=20, ofdm=0, rate->val=4106, val=10
signal=20, ofdm=0, rate->val=16789524, val=20
signal=110, ofdm=0, rate->val=4106, val=10
signal=110, ofdm=0, rate->val=16789524, val=20
signal=110, ofdm=0, rate->val=33583159, val=55
signal=110, ofdm=0, rate->val=50393198, val=110

but ALWAYS ofdm is 0, ie, it only sees CCK packets.

If I look over on channel 11, my neighbour has an 80211b device apparently, I see data packets at 11Mbps, again CCK.

-Andy

Andy Green

author

2007-07-31 13:49 UTC #14 lore raw

In reply to Ivo van Doorn

Quoted 6 lines · Somebody in the thread at some point

echo 16 > csr_offset
cat csr_value
This will read the TXRX_CSR0 register of rt73usb which controls the filtering of the frames. That will help determining if the missing frames have been droppen in the hardware or not.

after the echo, catting that spews

0x007eb162

repeatedly to the console.

-Andy

Ivo van Doorn

2007-07-31 14:07 UTC #7 lore raw

In reply to Andy Green

Quoted 3 lines

Quoted 1 line
At which rate should the other box be sending the frames?
54Mbps, I am a couple of metres from the AP.

Ok. That means we can at least assume several frames should be send with higher rates then 1 Mbs. ;)

Quoted 8 lines

Quoted 8 lines
Quoted 4 lines
# while [ 1 ] ; do ls -l / ; done
over an ssh link which is being carried on another wireless device on the same box associated on to channel 6...
Could you enable debugfs and do inside the "rt73usb" folder within the mac80211 debugfs entry do:

Quoted 8 lines

Quoted 6 lines
echo 16 > csr_offset
cat csr_value
This will read the TXRX_CSR0 register of rt73usb which controls the filtering of the frames. That will help determining if the missing frames have been droppen in the hardware or not.
I have to add debugfs in my .config for that, it is rebuilding.

Thanks.

Quoted 19 lines

However, I added the following debug line inside the loop at rt2x00_dev.c function
void rt2x00lib_rxdone(struct data_entry *entry, char *data,
	const int size, const int signal, const int rssi, const int ofdm)

		printk("signal=%d, ofdm=%d, rate->val=%d, val=%d\n", signal, ofdm,
rate->val, val);
and ran tcpdump at the same time. What I see is that even though tcpdump on ch 6 is only willing to show 1Mbps packets, packets with other rates passed through here, eg,
signal=20, ofdm=0, rate->val=4106, val=10
signal=20, ofdm=0, rate->val=16789524, val=20
signal=110, ofdm=0, rate->val=4106, val=10
signal=110, ofdm=0, rate->val=16789524, val=20
signal=110, ofdm=0, rate->val=33583159, val=55
signal=110, ofdm=0, rate->val=50393198, val=110

Quoted 4 lines

but ALWAYS ofdm is 0, ie, it only sees CCK packets.
If I look over on channel 11, my neighbour has an 80211b device apparently, I see data packets at 11Mbps, again CCK.

I think I have an idea why mac80211 always reports 1 MBs,
rt2x00 checks if PREAMBLE was enabled or not. If that is the case it sets the rate value to rate->val2
Mac80211 in turn only compares the value against rate->val which means that it won't find the rate and assume the lowest possible rate. I'll fix this by always setting the rate->val value instead (It isn't really important for mac80211 to know if the preamble bit was set anyway).

Quoted 5 lines

after the echo, catting that spews
0x007eb162
repeatedly to the console.

And here is a big problem..
This register is defined as:

#define TXRX_CSR0_DROP_CRC FIELD32(0x00020000)
#define TXRX_CSR0_DROP_PHYSICAL FIELD32(0x00040000)
#define TXRX_CSR0_DROP_CONTROL FIELD32(0x00080000)
#define TXRX_CSR0_DROP_NOT_TO_ME FIELD32(0x00100000)
#define TXRX_CSR0_DROP_TO_DS FIELD32(0x00200000)
#define TXRX_CSR0_DROP_VERSION_ERROR FIELD32(0x00400000)
#define TXRX_CSR0_DROP_MULTICAST FIELD32(0x00800000)
#define TXRX_CSR0_DROP_BORADCAST FIELD32(0x01000000)
#define TXRX_CSR0_DROP_ACK_CTS FIELD32(0x02000000)

Which means it will only pass multicast, broadcast and ACK_CTS frames. :S Always dropping CRC errors is correct, since enabling that will greatly upset any monitoring tool listening to the interface.

To see if it helps try:

echo 16 > csr_offset
echo 0x0002b162 > csr_value

This will disable all DROP bits (except for the CRC error) and thus should trigger more frames to be received by your interface. In the mean time I'll search why those bits weren't cleared when enabling the interface in monitor mode.

Which version are you using?
wireless-dev
rt2x00.git
rt2x00 cvs

Ivo

Andy Green

author

2007-07-31 14:35 UTC #8 lore raw

Quoted 6 lines · Somebody in the thread at some point

I think I have an idea why mac80211 always reports 1 MBs, rt2x00 checks if PREAMBLE was enabled or not. If that is the case it sets the rate value to rate->val2
Mac80211 in turn only compares the value against rate->val which means that it won't find the rate and assume the lowest possible rate. I'll fix this by always setting the rate->val value instead (It isn't

really

Quoted 1 line

important for mac80211 to know if the preamble bit was set anyway).

Somehow the rates seem to be correct now after your change to the DROP bits...

Quoted 10 lines

#define TXRX_CSR0_DROP_CRC FIELD32(0x00020000)
#define TXRX_CSR0_DROP_PHYSICAL FIELD32(0x00040000)
#define TXRX_CSR0_DROP_CONTROL FIELD32(0x00080000)
#define TXRX_CSR0_DROP_NOT_TO_ME FIELD32(0x00100000)
#define TXRX_CSR0_DROP_TO_DS FIELD32(0x00200000)
#define TXRX_CSR0_DROP_VERSION_ERROR FIELD32(0x00400000)
#define TXRX_CSR0_DROP_MULTICAST FIELD32(0x00800000)
#define TXRX_CSR0_DROP_BORADCAST FIELD32(0x01000000)
#define TXRX_CSR0_DROP_ACK_CTS FIELD32(0x02000000)

Quoted 2 lines

Which means it will only pass multicast, broadcast and ACK_CTS frames. :S Always dropping CRC errors is correct, since enabling that will

greatly upset

Quoted 1 line

any monitoring tool listening to the interface.

Well one day it will be nice if there is a stack-level way to turn it on and off. We can also pass in the radiotap part a flag to show if the packet's CRC was valid or not. The tools can then either turn on the filtering before the packets come or filter on good packets only.

Quoted 7 lines

To see if it helps try:
echo 16 > csr_offset
echo 0x0002b162 > csr_value
This will disable all DROP bits (except for the CRC error) and thus should trigger more frames to be received by your interface. In the mean time

I'll search

Quoted 1 line

why those bits weren't cleared when enabling the interface in monitor

mode.

Yes, that seems to have done it, thanks

15:20:34.157203 54.0 Mb/s 2437 MHz (0x0480) 214dB signal Data IV:1b30 Pad 20 KeyID 0
15:20:34.157206 24.0 Mb/s 2437 MHz (0x0480) 232dB signal Acknowledgment RA:00:11:50:ad:ce:38 (oui Unknown)
15:20:34.157942 54.0 Mb/s 2437 MHz (0x0480) 232dB signal Data IV:16aa Pad 20 KeyID 0
15:20:34.157945 36.0 Mb/s 2437 MHz (0x0480) 214dB signal Acknowledgment RA:00:19:d2:59:8f:d5 (oui Unknown)
15:20:34.161265 54.0 Mb/s 2437 MHz (0x0480) 214dB signal Data IV:1b31 Pad 20 KeyID 0
15:20:34.161268 24.0 Mb/s 2437 MHz (0x0480) 230dB signal Acknowledgment RA:00:11:50:ad:ce:38 (oui Unknown)
15:20:34.165809 1.0 Mb/s 2437 MHz (0x0480) 218dB signal Beacon (froh) [1.0* 2.0* 5.5* 11.0* Mbit] ESS CH: 6, PRIVACY 15:20:34.165812 54.0 Mb/s 2437 MHz (0x0480) 214dB signal Data IV:1b32 Pad 20 KeyID 0
15:20:34.165815 24.0 Mb/s 2437 MHz (0x0480) 232dB signal Acknowledgment RA:00:11:50:ad:ce:38 (oui Unknown)
15:20:34.166498 54.0 Mb/s 2437 MHz (0x0480) 232dB signal Data IV:16ab Pad 20 KeyID 0
15:20:34.166502 36.0 Mb/s 2437 MHz (0x0480) 214dB signal Acknowledgment RA:00:19:d2:59:8f:d5 (oui Unknown)

Quoted 4 lines

Which version are you using?
wireless-dev <---
rt2x00.git
rt2x00 cvs

-Andy

Ivo van Doorn

2007-07-31 14:46 UTC #9 lore raw

Quoted 8 lines · Andy Green

Quoted 6 lines · Somebody in the thread at some point
I think I have an idea why mac80211 always reports 1 MBs, rt2x00 checks if PREAMBLE was enabled or not. If that is the case it sets the rate value to rate->val2
Mac80211 in turn only compares the value against rate->val which means that it won't find the rate and assume the lowest possible rate. I'll fix this by always setting the rate->val value instead (It isn't

Quoted 5 lines

really
Quoted 1 line
important for mac80211 to know if the preamble bit was set anyway).
Somehow the rates seem to be correct now after your change to the DROP bits...

Excellent! :)

Quoted 12 lines

Quoted 10 lines
#define TXRX_CSR0_DROP_CRC FIELD32(0x00020000)
#define TXRX_CSR0_DROP_PHYSICAL FIELD32(0x00040000)
#define TXRX_CSR0_DROP_CONTROL FIELD32(0x00080000)
#define TXRX_CSR0_DROP_NOT_TO_ME FIELD32(0x00100000)
#define TXRX_CSR0_DROP_TO_DS FIELD32(0x00200000)
#define TXRX_CSR0_DROP_VERSION_ERROR FIELD32(0x00400000)
#define TXRX_CSR0_DROP_MULTICAST FIELD32(0x00800000)
#define TXRX_CSR0_DROP_BORADCAST FIELD32(0x01000000)
#define TXRX_CSR0_DROP_ACK_CTS FIELD32(0x02000000)
Quoted 2 lines
Which means it will only pass multicast, broadcast and ACK_CTS frames. :S Always dropping CRC errors is correct, since enabling that will

Quoted 7 lines

greatly upset
Quoted 1 line
any monitoring tool listening to the interface.
Well one day it will be nice if there is a stack-level way to turn it on and off. We can also pass in the radiotap part a flag to show if the packet's CRC was valid or not. The tools can then either turn on the filtering before the packets come or filter on good packets only.

Well the problem with the CRC errors is that, when enabled, mac80211 will be flooded with frames. Regular frames which are usually the interesting ones could get lost in there.
But you are right, having the stack to control the DROP filter would be a very nice feature. :)

Quoted 5 lines

Quoted 5 lines
To see if it helps try:
echo 16 > csr_offset
echo 0x0002b162 > csr_value

Quoted 7 lines

Quoted 2 lines
This will disable all DROP bits (except for the CRC error) and thus should trigger more frames to be received by your interface. In the mean time
I'll search
Quoted 1 line
why those bits weren't cleared when enabling the interface in monitor
mode.
Yes, that seems to have done it, thanks

Excellent :)

Quoted 4 lines

Quoted 4 lines
Which version are you using?
wireless-dev <---
rt2x00.git
rt2x00 cvs

Ok, rt2x00.git contains many changes to the initialization of the device, so it is a bit hard to compare at the moment. At least it is confirmed that rt2x00 can receive all frames in monitor mode and the problem area is the DROP filter.

I'll release rt2x00 2.0.5 later today with all those changes, including the rxdone rate selection fix. So if you could retest later to see if the problem disappeared in 2.0.5 it would be great. :)

Ivo

Ivo van Doorn

2007-07-31 15:02 UTC #10 lore raw

Hi,

Quoted 5 lines

Quoted 4 lines
Quoted 4 lines
Which version are you using?
wireless-dev <---
rt2x00.git
rt2x00 cvs

Quoted 7 lines

Ok, rt2x00.git contains many changes to the initialization of the device, so it is a bit hard to compare at the moment. At least it is confirmed that rt2x00 can receive all frames in monitor mode and the problem area is the DROP filter.
I'll release rt2x00 2.0.5 later today with all those changes, including the rxdone rate selection fix. So if you could retest later to see if the problem disappeared in 2.0.5 it would be great. :)

Ok, that was easier then I thought, rt2x00 2.0.5 _will_ contain the fix for this. I just noticed that when the first and only interface is a monitor interface the device was not being configured at all. This has now been fixed in rt2x00.git, so it will be part of the 2.0.5 release later today. :)

Ivo

Andy Green

author

2007-07-31 15:14 UTC #11 lore raw

Quoted 10 lines · Somebody in the thread at some point

Hi,
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
Which version are you using?
wireless-dev <---
rt2x00.git
rt2x00 cvs
Ok, rt2x00.git contains many changes to the initialization of the device, so it is a bit hard to compare at the moment. At least it is confirmed that rt2x00 can receive all frames in monitor mode and the problem area is the DROP filter.

Quoted 8 lines

Quoted 3 lines
I'll release rt2x00 2.0.5 later today with all those changes, including the rxdone rate selection fix. So if you could retest later to see if the problem disappeared in 2.0.5 it would be great. :)
Ok, that was easier then I thought, rt2x00 2.0.5 _will_ contain the fix for this. I just noticed that when the first and only interface is a monitor interface the device was not being configured at all. This has now been fixed in rt2x00.git, so it will be part of the 2.0.5 release later today. :)

Great, I will check for it on the serialmonkey site later and give it a go.

I just received four different kinds of cheap cards from ebuyer, I hoped to get a bcm43xx card again but you can't choose when the cards are only GBP8 each. So later I will see what can happen with the other cards that are new to me: Libertas on 88W8335 PC Card, Libertas USB stick 1286:1fab, and a Realtek PC Card RTL-8185.

Thanks to your help it looks like the first RT2571-based one is a winner ;-)

-Andy

Andy Green

author

2007-07-31 22:37 UTC #12 lore raw

Quoted 6 lines · Somebody in the thread at some point

Quoted 4 lines
Ok, that was easier then I thought, rt2x00 2.0.5 _will_ contain the fix for this. I just noticed that when the first and only interface is a monitor interface the device was not being configured at all. This has now been fixed in rt2x00.git, so it will be part of the 2.0.5 release later today. :)
Great, I will check for it on the serialmonkey site later and give it a go.

Ah I saw it went to git.kernel.org

Yes current rt2x00 git in there works fine for simple monitor mode now... thanks a lot for your hard work!

-Andy

Ivo van Doorn

2007-08-01 16:46 UTC #13 lore raw

Quoted 7 lines · Andy Green

Quoted 5 lines · Somebody in the thread at some point
Quoted 4 lines
Ok, that was easier then I thought, rt2x00 2.0.5 _will_ contain the fix for this. I just noticed that when the first and only interface is a monitor interface the device was not being configured at all. This has now been fixed in rt2x00.git, so it will be part of the 2.0.5 release later today. :)

Quoted 6 lines

Quoted 1 line
Great, I will check for it on the serialmonkey site later and give it a go.
Ah I saw it went to git.kernel.org
Yes current rt2x00 git in there works fine for simple monitor mode now... thanks a lot for your hard work!

Excellent! Good to hear that is working completely now. :)

Ivo