OK - first off, I am a Linux newbee, so please go easy!

I am autoconnecting to a RDP session on my N800. To do this, I use a script that autoconnects to my wireless network during the boot process. This way, I am sure the connection is made when the script runs to start RDesktop automatically.

All this works great. The problem is that I want to create a dummy network to trick the Nokia into thinking it IS connected incase I need to use the Nokia browser etc. I've read that DummyIAP only works with the N770 and not the N800.

I cannot find an easy set of instructions on how to make this happen. I've found some instructions on how to create an "dummy" ad-hoc connection, but I need to keep my original wireless connection alive. It seems that creating a ad-hoc connection, whether real or not, causes the Nokia to drop my connection when it trys to connect to the fake ad-hoc connection.

Any suggestions on how to create a dummy connection that won't break my autoconnected one?

Thanks

So... you have a script that connects you *to* a network (through iwconfig or something similar), but you need to trick the rest of the n800 into believing that you really *are* connected?

I think there's something with DBUS commands that could tell the maemo ICD (internet connectivity daemon) that you've connected..
Some of the stuff here looks promising, but it's not exactly what you're looking for.

Anyone with more DBUS experience got anything?

This creates a dummy connection which can then be selected in the connection dialog.

Thanks - I'll try that script. That appears to be the same script as what is suggested on Maemo except it is using version 2. Perhaps that will make the difference. I'll report back my findings.

When I tried the original DummyIAP script (version 1) it make a DEFAULT entry that I could connect to in the connections wizard, but it would break my real wireless connection in the process.

Perhaps the real solution is to connect to the dummyIAP first and then connect automatically to my real wireless connection. I'll have to research how to connect to the DEFAULT network via a script so I could add that to my existing autoconnect script. The only stumbling block that might occur is that I am connecting during the boot process (so the tablet is already connected by the time the desktop appears). I'm not sure if the stock IC is far enough along at that point to allow someone to connect to the DEFAULT network.

That correct. I have a script that runs during the boot process, so that by the time the tablet is finished the boot process, I am already connected to the network. I do this because I then immediately use another script to start a RDP session and I don't want the RDP session to fail because the network isn't connected.

However, when/if I close out the RDP session, I'd like to be able to use the Nokia like normal without having the connect 'again' to the network manually using the Nokia IC. It would be nice if the Nokia already assumed I was connected so I could use the internet browser etc.

It's not the end of the world for me to simply manually reconnect to the network. But I figured there has to be a way to have a Dummy network accepted by the Nokia. The problem is that I am a Linux newbee (I'm basically using other peoples scripts to do the above listed things), so I am having to learn all this from scratch.

The easiest way... is to install maemo-control-usb. I installed this and it looks like creates a dummy network as above, the only difference I can see is that it's called USB.

I even uninstalled the package and this connection remains!

I think the USB networking stuff is supplementary, and not implicit in the dummy connection itself.

I just tried this under Diablo, but it does not work. I can see the USB connection in the connectivity settings dialog, but not in the select connection box. Are you using Chinook or Diablo?

As Diablo was released on the 24th of June, and the previous post was on the 23rd, it seems likely that BoxOfSnoo was running Chinook.

Moreover, this is a known issue with Diablo. 3306

Thanks for the link, I did not know this was a known bug...