ipcop-devel Mailing List for IPCop Firewall

On 3/28/2013 7:08 AM, Darren Critchley wrote:
> You guys do realize that over here in North America, the clock shifted
> back on the 10th of March. So all this talk of trying to make it in time
> for the clock shift is a mute point for this side of the world.
>
> Regards
> Darren
>
>
> On 03/28/2013 06:13 AM, Achim Weber wrote:
>>> As for the release, I think 2.1.1 is not ready tested yet.
>> This should say: I think 2.1.1 needs more lead time for a release, with release
>> candidate etc.... not just two days (before clock shift).
>>
>> Achim

Is there anyone whose clock will not be correct by what we already have 
in 2.0.6? As you said, we passed that point earlier this month and no 
issues with time.

-- 
Dave Studeman
http://www.raqcop.com

On 3/28/2013 11:24 AM, g....@fr... wrote:
>
>
> ----- Mail original -----
>> De: "Achim Weber" <dot...@gm...>
>> À: ipc...@li...
>> Envoyé: Jeudi 28 Mars 2013 14:13:52
>> Objet: Re: [IPCop-devel] Progress on 2.1
>>
>>> As for the release, I think 2.1.1 is not ready tested yet.
>>
>> This should say: I think 2.1.1 needs more lead time for a release,
>> with release
>> candidate etc.... not just two days (before clock shift).
>>
>> Achim
>>
> I agree that 2.1.1 would need at least probably a beta and an .rc.
>
> I slowed probably the process a lot with my suggestion to use the 3.4 kernel. I haven't found time to progress faster.
> Any issue compiling external driver for 3.4 should be fixed now as sangoma released wanpipe-7.0.x
> The big jump in the release number from 3.5.28 mean nothing for the code, only a sync with the windows driver version number.
> I haven't yet compiled that crap code.
>
> I am compiling those days ipcop with kernel 3.4.37 and I have seen 3.4.38 should arrive soon.
>
> I haven't had the time to test the install a lot with 3.4 and tune the kernel config.
>
> The issue with opensuse-1.12.3 to compile ipcop is probably present with any distrib compiling devtmpfs.
> In stage2, mount --move /dev /dev1 is not supported.
>
> I think we should move the mknod from stage2 to make.sh, so before mouting /dev
> Acting like LFS in chap-6.2, that should work.
> That will require adding mknode to the list of commands allowed by sudo.
>
> Could some of you report if devtmps is really the issue? OpenSuse-1.12.3 has a 3.7 kernel.
> I had no issue compiling on debian v6 squeeze with a custom kernel updated to 3.4 and a kernel .config that is mostly an upgrade from debian next with 3.2 kernel. I don't think I had devtmps activated.
>
> Probably we should update perl to debian wheezy (5.14.2.20..) or in a bit more than one year, our old perl will not be maintained anymore.
>
> I forgot what code use ulogd-1. ulogd-1 is end-of-life.
> To my understanding, misdn should replace isdn-4kutils.
>
> I should finish the kernel upgrade in the few days with a bit of focus.
>
> Gilles
>

Debian Squeeze with the stock kernel works fine. I have no good answer 
on OpenSuSE 12.3 yet. Of course my most powerful and fault tolerant 
compile machine is my openSuSE machine.

There has to be other systems that have the same issues.

-- 
Dave Studeman
http://www.raqcop.com

----- Mail original -----
> De: "Achim Weber" <dot...@gm...>
> À: ipc...@li...
> Envoyé: Jeudi 28 Mars 2013 14:13:52
> Objet: Re: [IPCop-devel] Progress on 2.1
> 
> > As for the release, I think 2.1.1 is not ready tested yet.
> 
> This should say: I think 2.1.1 needs more lead time for a release,
> with release
> candidate etc.... not just two days (before clock shift).
> 
> Achim
> 
I agree that 2.1.1 would need at least probably a beta and an .rc.

I slowed probably the process a lot with my suggestion to use the 3.4 kernel. I haven't found time to progress faster.
Any issue compiling external driver for 3.4 should be fixed now as sangoma released wanpipe-7.0.x
The big jump in the release number from 3.5.28 mean nothing for the code, only a sync with the windows driver version number.
I haven't yet compiled that crap code.

I am compiling those days ipcop with kernel 3.4.37 and I have seen 3.4.38 should arrive soon.

I haven't had the time to test the install a lot with 3.4 and tune the kernel config.

The issue with opensuse-1.12.3 to compile ipcop is probably present with any distrib compiling devtmpfs.
In stage2, mount --move /dev /dev1 is not supported.

I think we should move the mknod from stage2 to make.sh, so before mouting /dev
Acting like LFS in chap-6.2, that should work.
That will require adding mknode to the list of commands allowed by sudo.

Could some of you report if devtmps is really the issue? OpenSuse-1.12.3 has a 3.7 kernel.
I had no issue compiling on debian v6 squeeze with a custom kernel updated to 3.4 and a kernel .config that is mostly an upgrade from debian next with 3.2 kernel. I don't think I had devtmps activated.

Probably we should update perl to debian wheezy (5.14.2.20..) or in a bit more than one year, our old perl will not be maintained anymore.

I forgot what code use ulogd-1. ulogd-1 is end-of-life.
To my understanding, misdn should replace isdn-4kutils.
 
I should finish the kernel upgrade in the few days with a bit of focus.

Gilles

You guys do realize that over here in North America, the clock shifted 
back on the 10th of March. So all this talk of trying to make it in time 
for the clock shift is a mute point for this side of the world.

Regards
Darren


On 03/28/2013 06:13 AM, Achim Weber wrote:
>> As for the release, I think 2.1.1 is not ready tested yet.
> This should say: I think 2.1.1 needs more lead time for a release, with release
> candidate etc.... not just two days (before clock shift).
>
> Achim
>
>
> ------------------------------------------------------------------------------
> Own the Future-Intel® Level Up Game Demo Contest 2013
> Rise to greatness in Intel's independent game demo contest.
> Compete for recognition, cash, and the chance to get your game
> on Steam. $5K grand prize plus 10 genre and skill prizes.
> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
> _______________________________________________
> IPCop-devel mailing list
> IPC...@li...
> https://lists.sourceforge.net/lists/listinfo/ipcop-devel
>

> As for the release, I think 2.1.1 is not ready tested yet.

This should say: I think 2.1.1 needs more lead time for a release, with release
candidate etc.... not just two days (before clock shift).

Achim

> What's left to do before v2.1.1 can be released? It's getting close to
> another clock shift, when an updated tzdata might be useful to some.

I have added some new texts from urlfilter to the lang db which need
translations now.

As for the release, I think 2.1.1 is not ready tested yet. There are may some
changes needed. IIRC Gilles wanted to upgrade kernel to 3.4!?

Maybe a 2.0.7 (svn copy 2.0.6 + new tzdata) could be switched in!?

Achim

----- Mail original -----
> De: "David W Studeman" <da...@da...>
> À: ipc...@li...
> Envoyé: Mercredi 27 Mars 2013 23:11:32
> Objet: [IPCop-devel] Build 6830 Fails building immediately after toolchain	load.
> 
> In the most recent svn pulls I have this error when I try to build:
> ----------snip----------------------------------------------------------
> mkdir -p /dev1
> # Avoid writing our /dev move to mtab to look more like a ordinary
> mtab.
> # When this line was alone in mtab, it caused some 'df' issue.
> mount --no-mtab --move /dev /dev1
> mount: wrong fs type, bad option, bad superblock on /dev,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail or so
> make: *** [/usr/src/files_i486/02_base/stage2] Error 32
> 
> ------------------------------------------------------------------------
> 
> The system is OpenSuSE 12.3 64 bit. Note that the toolchain itself
> builds
> fine on this system.
> 
> --
> Dave Studeman
> http://www.raqcop.com
> 

I encounter the same issue on the same distrib a few days ago.
I think we would need to remove the trick that move  /dev to /dev1, to create /dev/null and /dev/console.
The reason should be that only one devtmpfs could exist by design and that could be moved.
I commented the lines starting from mkdir -p /dev1 until rm -fr /dev1 and build was fine.
- I haven't tested to install that build, I am unsure /dev/null, /dev/console may miss as I don't think /dev is include/installed.
- probably we should switch to devtmpfs (opinion?)
 
Don't try to run test (aka ./make.sh build test). My machine hang during parted tests.
I haven't find the time to investigate why/how for now.

Gilles

David W Studeman wrote:

> In the most recent svn pulls I have this error when I try to build:
> ----------snip----------------------------------------------------------
> mkdir -p /dev1
> # Avoid writing our /dev move to mtab to look more like a ordinary mtab.
> # When this line was alone in mtab, it caused some 'df' issue.
> mount --no-mtab --move /dev /dev1
> mount: wrong fs type, bad option, bad superblock on /dev,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail or so
> make: *** [/usr/src/files_i486/02_base/stage2] Error 32
> 
> ------------------------------------------------------------------------
> 
> The system is OpenSuSE 12.3 64 bit. Note that the toolchain itself builds
> fine on this system.
> 
Correction, it is build 6935 eg the latest.
-- 
Dave Studeman
http://www.raqcop.com 

In the most recent svn pulls I have this error when I try to build:
----------snip----------------------------------------------------------
mkdir -p /dev1
# Avoid writing our /dev move to mtab to look more like a ordinary mtab.
# When this line was alone in mtab, it caused some 'df' issue.
mount --no-mtab --move /dev /dev1
mount: wrong fs type, bad option, bad superblock on /dev,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so
make: *** [/usr/src/files_i486/02_base/stage2] Error 32

------------------------------------------------------------------------

The system is OpenSuSE 12.3 64 bit. Note that the toolchain itself builds 
fine on this system.

-- 
Dave Studeman
http://www.raqcop.com 

Hi

What's left to do before v2.1.1 can be released? It's getting close to
another clock shift, when an updated tzdata might be useful to some.

--
Eric

Bugs item #3609113, was opened at 2013-03-26 04:28
Message generated for change (Tracker Item Submitted) made by lovelymat
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3609113&group_id=40604

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: 2.0.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: MAT (lovelymat)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dual Red Interface

Initial Comment:
Hi,

I have 2 different static IPs of internet service providers that I want to  configure on Dual Red Interfaces.
Please tell me how I can configure dual Red Interfaces and enable failover feature on IPCOP as well tell which IPCOP's version support these features.

Thanks
MAT

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=428516&aid=3609113&group_id=40604

>> Following Todd Wiegel's report on the ipcop-user mailing list that he was
>> unable to turn off caching, I had a look at the code in the
>> makesquidconf.plscript and there is a line that should print "cache
>> deny all" if this test
>> fails:
>> if (($proxysettings{'CACHE_SIZE'}>  0) || ($proxysettings{'CACHE_MEM'}>  0))
>>
>> ie, both CACHE_SIZE and CACHE_MEM have to be 0 to turn off caching
>
> This was introduced in svn rev. #5831 [1] from Olaf.
>
>
>> But there is error checking in proxy.cgi that prevents CACHE_MEM being less
>> than 1
>>
>> So, at the moment, I think "cache deny all" is broken.
>
> Think so too.
>
>
>> What's the best way to repair? Allow a zero for CACHE_MEM? What might that
>> break?
>
> I think if it can be set to zero, there should be a check if it is>0 before
> writing "cache_mem $proxysettings{'CACHE_MEM'} MB" to squid.conf.

cache_mem does not break when set to 0 MB. So allowing 0 for CACHE_MEM 
in proxy.cgi is sufficient.

CACHE_MEM was added to be able to have (limited) caching and not bother 
with the (slow) harddisk.

>> The Admin Manual refers to turning off harddisk caching with a 0 in
>> CACHE_SIZE, but it doesn't mention CACHE_MEM, so perhaps the fix lies in
>> the makesquidconf.pl script?
>>
>> Eric
>
> I think the correct way to fix this would be to change the check in proxy.cgi so
> CACHE_MEM can be set to 0 too. If this is changed, the docu too should mention
> the CACHE_MEM in the "disable cache" section.

I'll change proxy.cgi to also allow 0 for CACHE_MEM.


Olaf

I got it working but I still have to do

modprobe usbserial

after boot or insert of USB Modem otherwise no ttyUSB interfaces exist 
so annoying

It seems to stop working after a few mins though

On 8/03/2013 5:41 AM, da...@da... wrote:
> On 2013-03-07 09:39, Arion Blishen wrote:
>> The 25Mbs speed limit is been found by people on the whirlpool forums
>>
>
> Ah ok. Probably a carrier choice?
>
> Did you ever get it working with what is actually provided in IPCop?
>
> Dave

On 2013-03-07 09:39, Arion Blishen wrote:
> The 25Mbs speed limit is been found by people on the whirlpool forums
>

Ah ok. Probably a carrier choice?

Did you ever get it working with what is actually provided in IPCop?

Dave

On 2013-03-07 09:37, Arion Blishen wrote:
> Under the dialup page.
>
> Can an option in the Interface: drop down box be 3G/4G USB Modem ?
>
> Which would put in the number to dial as *99#
> default the interface to ttyUSB0 in the drop down list
> Computer to modem rate: to highest rate
>
> instead of having to enter the Modem INIT for this Profile:
> AT+CGDCONT=1,"IP","internet"
> just have a box that asks for the APN and a box for the PIN which can 
> be
> blank
>
> most 3G connections do not need a username or password so allow it to 
> be
> left blank
>

I've experienced that as well in the past. I used nebulous nonsensical 
characters to put something in there. The reason the blanks exist at all 
is because of all the dialup connections that have been used on IPCop in 
the past and present. I've had my equipment with me in hotels that I had 
to use dialup until I got cellular data. In 2003 I was lucky to get 
130kbs with Sprint PCS (CDMA). Things have gotten much better.

If the developers have time and/or interest in doing so, it certainly 
would be possible to put the APN and pin blank into the gui if 3g is 
chosen in the cl setup as red. Trouble is, how far would one want to 
take this? Single purpose cellular routers have all the auto bells and 
whistles since that is their sole market to be as zero config as 
possible.

The interface rate usually is ignored as you cannot control it in 
cellular data outside of the driver. Only in rare cases where a high 
speed non usb serial is used would the data rate matter. In the 3G 
drivers that are usbserial based, the speed is limited by the endpoint 
buffer size as well as number of urbs. A serial rate means nothing to 
those drivers as far as I can tell.

Dave

The 25Mbs speed limit is been found by people on the whirlpool forums

http://whirlpool.net.au/wiki/router_openwrt

On 1/03/2013 2:30 PM, David W Studeman wrote:
> On 2/28/2013 12:10 PM, Arion Blishen wrote:
>> I found a way to get the Telstra 4G USB Modem to work with IPCop. The
>> model I have is ZTE MF821 there is also a post paid model Sierra 320U
>> which should be able to work the same just has different USB IDs
> You say nothing of which version of IPCop you are using. If 2.x, did the
> built in usb mode change program that uses udev NOT work by simply
> plugging the device in and not automatically load a suitable usbserial
> driver from the kernel? A lot of work was put into this very feature
> prior to IPCop 2.0.0's release.
>
>> I used the instructions in
>>
>> http://www.eigenmagic.com/2012/03/14/how-to-get-telstra-4g-mobile-broadband-working-with-linux/
>>
>> Also see this thread
>>
>> http://forums.whirlpool.net.au/forum-replies.cfm?t=2060627&p=-1
>>
>> but I have to run
>>
>> modprobe usbserial
>>
>> as the /dev/ttyUSB0 etc are not created automatically on boot or at any time
> I just looked up the values and they are in recent udev modeswitch rules
> as of IPCop 2.0.6 and possibly earlier:
>
> # ZTE MF820 4G LTE
> ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="0166", RUN+="usb_modeswitch
> '%b/%k'"
>
> If you unplug the modem on a running system and plug it back in what
> happens? Unfortunately modeswitch doesn't seem to get it out of cdrom
> mode during boot, at least on some systems such as mine and the
> usbserial related driver will NOT load in cdrom mode. I added this to my
> /etc/rc.d/rc.event.local to get around the boot limitation:
>
> /usr/sbin/usb_modeswitch -v 0x19d2 -p 0x2000 -m 0x01 -M
> "5553424312345679000000000000061b000000020000000000000000000000"
>
> This gets it out of cdrom mode and the proper driver loads automatically
> for my hardware per the above example. If the system is up and running
> already, unplugging the modem and plugging it back in works
> automatically via modeswitch and subsequent usbserial driver load once
> the switch takes place. In other words, usb modeswitch in IPCop works
> perfectly on a running system.
>> Also any chance that QMI WWAN driver support can be added to IPCop. This
>> makes the USB Modems run as a network interface rather than using PPP
>> and is much faster as PPP is limited to 25Mbit
>>
> The QMI WWAN driver will only activate the ethernet part of the chips
> and will still require much configuration to be usable since you still
> need to control the cellular data end via Hayes AT commands pointed to a
> usbserial type device node. I'd rather just skip the foofala and
> communicate directly to the node via the ppp dialer as we do now. Fake
> ethernet drivers on cellular data devices go back years but is not all
> the rage for good reason. Still, it's up to the devs if they want to
> incorporate it into IPCop.
>
> Where did you get the 25mbs figure for ppp? My connection using dialup
> is 42mbs between me and my tower using a tmobile rocket card and the
> 42mbs is a moot point since I and everyone else connected to that tower
> use the same network backhaul to the tower putting it right in oversold
> cable internet territory where you share the same pipe with over 100
> other people, probably 1000 in this case. I have yet to break 10mbs even
> at 4am even though I connect to the tower at 42mbs as I said earlier
> which has nothing to do with ppp. Seems as if nobody considers the
> backhaul to the tower which could be the data equivalent of a goat trail
> for all we know.
>
> In your case as usually is the case, it's all a matter of having the
> right AT wordstring to get the most out of it, ie, the so called 4G mode.
>
> As far as 4G versus 3G, well, according to the ITU, anything below
> 160mbs in the download direction for wireless data is NOT 4G, call it
> infinite G if it makes you feel better. In other words, cellular
> carriers went overboard in advertising, once one lied, the others wound
> up following suite rather than disputing the first liar's
> disinformation. The ITU seems to have thrown it's hands in the air once
> this got out of hand. Lies and damned lies. What? From cellular
> carriers? Say it isn't so!
>

Under the dialup page.

Can an option in the Interface: drop down box be 3G/4G USB Modem ?

Which would put in the number to dial as *99#
default the interface to ttyUSB0 in the drop down list
Computer to modem rate: to highest rate

instead of having to enter the Modem INIT for this Profile: 
AT+CGDCONT=1,"IP","internet"
just have a box that asks for the APN and a box for the PIN which can be 
blank

most 3G connections do not need a username or password so allow it to be 
left blank

Is it really necessary to check those values at all, unless switching cacheing 
on?


> Hi
> 
> Following Todd Wiegel's report on the ipcop-user mailing list that he was
> unable to turn off caching, I had a look at the code in the
> makesquidconf.plscript and there is a line that should print "cache
> deny all" if this test
> fails:
> if (($proxysettings{'CACHE_SIZE'} > 0) || ($proxysettings{'CACHE_MEM'} >
>  0))
> 
> ie, both CACHE_SIZE and CACHE_MEM have to be 0 to turn off caching
> 
> But there is error checking in proxy.cgi that prevents CACHE_MEM being less
> than 1
> 
> So, at the moment, I think "cache deny all" is broken.
> 
> What's the best way to repair? Allow a zero for CACHE_MEM? What might that
> break?
> 
> The Admin Manual refers to turning off harddisk caching with a 0 in
> CACHE_SIZE, but it doesn't mention CACHE_MEM, so perhaps the fix lies in
> the makesquidconf.pl script?
> 
> Eric
> 

-- 
Robert Ladyman
File-Away Limited
3 Ralston Business Centre, Newtyle, Blairgowrie
Perthshire  PH12 8TL SCOTLAND
Tel: +44 (0) 1828 898 158
Mobile: +44 (0) 7732 771 649
http://www.file-away.co.uk

============================================
Registered Office: 32 Church Street, Newtyle, Blairgowrie
Perthshire, PH12 8TZ SCOTLAND
Registered in Scotland, Company Number SC222086

Hi Eric

> Following Todd Wiegel's report on the ipcop-user mailing list that he was
> unable to turn off caching, I had a look at the code in the
> makesquidconf.plscript and there is a line that should print "cache
> deny all" if this test
> fails:
> if (($proxysettings{'CACHE_SIZE'} > 0) || ($proxysettings{'CACHE_MEM'} > 0))
> 
> ie, both CACHE_SIZE and CACHE_MEM have to be 0 to turn off caching

This was introduced in svn rev. #5831 [1] from Olaf.


> But there is error checking in proxy.cgi that prevents CACHE_MEM being less
> than 1
> 
> So, at the moment, I think "cache deny all" is broken.

Think so too.


> What's the best way to repair? Allow a zero for CACHE_MEM? What might that
> break?

I think if it can be set to zero, there should be a check if it is >0 before
writing "cache_mem $proxysettings{'CACHE_MEM'} MB" to squid.conf.


> The Admin Manual refers to turning off harddisk caching with a 0 in
> CACHE_SIZE, but it doesn't mention CACHE_MEM, so perhaps the fix lies in
> the makesquidconf.pl script?
> 
> Eric

I think the correct way to fix this would be to change the check in proxy.cgi so
CACHE_MEM can be set to 0 too. If this is changed, the docu too should mention
the CACHE_MEM in the "disable cache" section.

What do the others think, Olaf, Marco?


Achim

[1]
http://ipcop.svn.sourceforge.net/viewvc/ipcop/ipcop/trunk/html/cgi-bin/proxy.cgi?r1=5814&r2=5831

Hi

Following Todd Wiegel's report on the ipcop-user mailing list that he was
unable to turn off caching, I had a look at the code in the
makesquidconf.plscript and there is a line that should print "cache
deny all" if this test
fails:
if (($proxysettings{'CACHE_SIZE'} > 0) || ($proxysettings{'CACHE_MEM'} > 0))

ie, both CACHE_SIZE and CACHE_MEM have to be 0 to turn off caching

But there is error checking in proxy.cgi that prevents CACHE_MEM being less
than 1

So, at the moment, I think "cache deny all" is broken.

What's the best way to repair? Allow a zero for CACHE_MEM? What might that
break?

The Admin Manual refers to turning off harddisk caching with a 0 in
CACHE_SIZE, but it doesn't mention CACHE_MEM, so perhaps the fix lies in
the makesquidconf.pl script?

Eric

On 2/28/2013 12:10 PM, Arion Blishen wrote:
> I found a way to get the Telstra 4G USB Modem to work with IPCop. The
> model I have is ZTE MF821 there is also a post paid model Sierra 320U
> which should be able to work the same just has different USB IDs

You say nothing of which version of IPCop you are using. If 2.x, did the 
built in usb mode change program that uses udev NOT work by simply 
plugging the device in and not automatically load a suitable usbserial 
driver from the kernel? A lot of work was put into this very feature 
prior to IPCop 2.0.0's release.

> I used the instructions in
>
> http://www.eigenmagic.com/2012/03/14/how-to-get-telstra-4g-mobile-broadband-working-with-linux/
>
> Also see this thread
>
> http://forums.whirlpool.net.au/forum-replies.cfm?t=2060627&p=-1
>
> but I have to run
>
> modprobe usbserial
>
> as the /dev/ttyUSB0 etc are not created automatically on boot or at any time

I just looked up the values and they are in recent udev modeswitch rules 
as of IPCop 2.0.6 and possibly earlier:

# ZTE MF820 4G LTE
ATTRS{idVendor}=="19d2", ATTRS{idProduct}=="0166", RUN+="usb_modeswitch 
'%b/%k'"

If you unplug the modem on a running system and plug it back in what 
happens? Unfortunately modeswitch doesn't seem to get it out of cdrom 
mode during boot, at least on some systems such as mine and the 
usbserial related driver will NOT load in cdrom mode. I added this to my 
/etc/rc.d/rc.event.local to get around the boot limitation:

/usr/sbin/usb_modeswitch -v 0x19d2 -p 0x2000 -m 0x01 -M 
"5553424312345679000000000000061b000000020000000000000000000000"

This gets it out of cdrom mode and the proper driver loads automatically 
for my hardware per the above example. If the system is up and running 
already, unplugging the modem and plugging it back in works 
automatically via modeswitch and subsequent usbserial driver load once 
the switch takes place. In other words, usb modeswitch in IPCop works 
perfectly on a running system.
>
> Also any chance that QMI WWAN driver support can be added to IPCop. This
> makes the USB Modems run as a network interface rather than using PPP
> and is much faster as PPP is limited to 25Mbit
>

The QMI WWAN driver will only activate the ethernet part of the chips 
and will still require much configuration to be usable since you still 
need to control the cellular data end via Hayes AT commands pointed to a 
usbserial type device node. I'd rather just skip the foofala and 
communicate directly to the node via the ppp dialer as we do now. Fake 
ethernet drivers on cellular data devices go back years but is not all 
the rage for good reason. Still, it's up to the devs if they want to 
incorporate it into IPCop.

Where did you get the 25mbs figure for ppp? My connection using dialup 
is 42mbs between me and my tower using a tmobile rocket card and the 
42mbs is a moot point since I and everyone else connected to that tower 
use the same network backhaul to the tower putting it right in oversold 
cable internet territory where you share the same pipe with over 100 
other people, probably 1000 in this case. I have yet to break 10mbs even 
at 4am even though I connect to the tower at 42mbs as I said earlier 
which has nothing to do with ppp. Seems as if nobody considers the 
backhaul to the tower which could be the data equivalent of a goat trail 
for all we know.

In your case as usually is the case, it's all a matter of having the 
right AT wordstring to get the most out of it, ie, the so called 4G mode.

As far as 4G versus 3G, well, according to the ITU, anything below 
160mbs in the download direction for wireless data is NOT 4G, call it 
infinite G if it makes you feel better. In other words, cellular 
carriers went overboard in advertising, once one lied, the others wound 
up following suite rather than disputing the first liar's 
disinformation. The ITU seems to have thrown it's hands in the air once 
this got out of hand. Lies and damned lies. What? From cellular 
carriers? Say it isn't so!

-- 
Dave Studeman
http://www.raqcop.com