Comments on: Huawei E220

By: Jaco Kroon

Jaco Kroon — Mon, 13 Oct 2008 09:59:34 +0000

Hi,

This is contradictory to what I’ve been told on the GLUG-tech mailing list by someone that worked on firmware for a similar device. I’m unfortunately unable to locate the email at the moment. My understanding was similar to yours. I’m not sure how widespread the problem is, but it does seem to be specific to the Huawei modems.

Even the above eventually broke, so I just added something to restart pppd in ip-up, the box is unfortunately off at the moment, but IIRC it looks something like this:

if [[ $DNS1 = "10.11.12.13" ]]; then
kill -HUP $PPPD_PID
exit 0
fi

Not sure whether $PPPD_PID is standard, but it exists on Gentoo, and I’ll abuse it for as long as is required. This so far is the only 100 % surefire way I’ve found of dealing effectively with the problem – whatever may be the trigger of that.

Please see my other posts regarding Vodacom to understand why I’ve simply stopped caring and is now in a place of calm where my DSL at home should be installed at home in the next few hours, and I’ll be updating my ip-up on my laptop to deal with the sack options by disabling it whenever the 3G link comes up, and re-enabling it whenever it goes down again.

For my servers out in the field, all of them that makes use of 3G for failover are still struggling with the sack problem. Fortunately this isn’t overly serious as it’s mostly web browsing (which goes into transparent proxies that hides the problem) and mail (which gets retried in a few minutes, also hiding the problem).

I stopped getting the “Linux is not a supported platform” when I started threatening with legal action against what they’re doing to my TCP streams. Now they’ve shown that it’s a CISCO router making the changes, and in spite of me proving that what they’re doing is illogical and pointless they insist on still doing it, and looking to fix their code. Anyway, I don’t want to go all red faced again, so I’ll stop right here.

By: diepes

diepes — Mon, 13 Oct 2008 07:49:05 +0000

You mentioned.
>>The bottom line is this: The firmware on the Huawei E220
>> (and by implication the E270 and probably others too) is broken.

My understanding is that the modem is not involved in the ppp negotiation, it just converts the data from usb/serial/bluetooth to GSM.

The only commands the modem uses is the AT commands to setup the device in the chat script.

The ppp session terminates on some NAS equipment at the provider (similar with dsl).

That is why you would see the same behavior using any usb modem and even with my bluetooth connected Samsung 3G phone.

I still think more of us should log calls with our 3G providers to fix there ppp software. (While we work around them with a patch)
I got the standard reply of ‘Linux is not a supported platform”

By: Jaco Kroon

Jaco Kroon — Wed, 13 Aug 2008 08:19:55 +0000

I replied to the above with:

They don’t. I’m attaching the debug output below, look at what happens though (And some of this is speculation), initially we send a confreq, the modem (not vodacom, because the ppp only runs to the modem) then responds with auth chap MD5 and a magic, which we then rejet – indicating that I haven’t supplied credentials to pppd. Eventually the device actually connects with the GSM network, issues a DiscReq to us so that we can re-establish parameters (because it now got the info from GSM, I suspect), now, when we send the ConfReq for IPCP we send a request for addr, as well as ms-dns1 and 2 – which is all we really want. It then responds with with no addr and both dns and wins (which afaik it _SHOULD_NOT_ respond with as we haven’t requested it). This hops a couple of times, but notice that with the patched pppd it now sends the wins back indicating that we’re willing to accept it. I think I’m going to mod the patch to only do this with a parameter option of acceptwins in order to attempt getting it into mainline if other people find that this works for them too. Now last night the number of hops was fewer, but the result was the same, eventually it sends a ConfReq with no parameters, at which point we ConfNak it due to missing addr info, after which it rejects the WINS servers (in other words – NO WINS INFO IN THE END), we then send another confreq that’s near identical to the original, except we now have 10.11.12.13 and 10.11.12.14 as the initial dns servers as supplied earlier, this now gets Nak’ed and the correct data is _finally_ provided, and our responding Req is Ack’ed and we’ve got lift-off.

I hope this confusing explanation expresses somewhat accurately what I understand of the problem.

You’ll notice that the peer IP is still bogus – this does not matter at all. That IP is not used ANYWHERE except for two routes

1. A route to the pppd peer ip (unused except if you want to ping the pppd peer or something).
2. The default route added by pppd if you have the defaultroute option set, and even then it really doesn’t matter and I don’t know why pppd adds a “via” rule instead of a “dev” rule from the start anyway.

Regards,
Jaco Kroon

Connect: ppp2 <–> /dev/ttyUSB0
sent [LCP ConfReq id=0x1 ]
rcvd [LCP ConfReq id=0x3 ]
No auth is possible
sent [LCP ConfRej id=0x3 ]
rcvd [LCP ConfAck id=0x1 ]
rcvd [LCP ConfReq id=0x4 ]
sent [LCP ConfAck id=0x4 ]
sent [LCP EchoReq id=0x0 magic=0xf250f1b5]
sent [IPCP ConfReq id=0x1 ]
rcvd [LCP DiscReq id=0x5 magic=0x455367cd]
rcvd [LCP EchoRep id=0x0 magic=0x455367cd f2 50 f1 b5]
rcvd [IPCP ConfNak id=0x1 ]
sent [IPCP ConfReq id=0x2 ]
rcvd [IPCP ConfNak id=0x2 ]
sent [IPCP ConfReq id=0x3 ]
rcvd [IPCP ConfNak id=0x3 ]
sent [IPCP ConfReq id=0x4 ]
rcvd [IPCP ConfReq id=0x0]
sent [IPCP ConfNak id=0x0 ]
rcvd [IPCP ConfRej id=0x4 ]
sent [IPCP ConfReq id=0x5 ]
rcvd [IPCP ConfNak id=0x5 ]
sent [IPCP ConfReq id=0x6 ]
rcvd [IPCP ConfAck id=0x6 ]
rcvd [IPCP ConfReq id=0x1]
sent [IPCP ConfAck id=0x1]
Could not determine remote IP address: defaulting to 10.64.64.66
local IP address 196.46.172.91
remote IP address 10.64.64.66
primary DNS address 196.207.36.251
secondary DNS address 196.207.36.254
Script /etc/ppp/ip-up started (pid 12581)
Script /etc/ppp/ip-up finished (pid 12581), status = 0×0

By: Jaco Kroon

Jaco Kroon — Wed, 13 Aug 2008 08:19:28 +0000

I received this reply on a discussion on the GLUG mailing list:

BTW, I note that the vodafone-mobile-connect-card-driver-for-linux (from https://forge.betavine.net/projects/vodafonemobilec/) package (not a driver, rather a python-twisted-based GUI for configuring and connecting GPRS/3G/HSDPA modems/connections with wvdial) has settings for various network providers, and the one for Vodacom-SA has static DNS IPs, and by default will have the “use static DNS servers” or simlar option checked …

Why anyone would actually want to run WINS on an internet connection though is beyond me, but in case they did, nss_wins may be of some benefit then too …