Bug 16172 – Webkit based browsers are no longer able to properly handle form submission in the Siemens 6520 based routers used by Aliant (Canadian ISP)

• Component: Forms
• Status: RESOLVED INVALID

[Tim Dove]

As this issue is with the web interface of a router, I have saved the affected page as a web-archive and uploaded it to a personal webspace. 

Model: Siemens / Efficient Networks Speedstream 6250 DSL Modem/Router.
ISP: Bell-Aliant

On any interface pages that have multiple buttons, Safari v3.0.4 and any other current webkit based browsers (I have tested Safari v3.0.4 for Mac/PC, Shiira, and OmniWeb) are unable to load the page properly when you click on the button to advance to the next page. The returned error is "Form Input - Error: Invalid Submission Value". IE and gecko based browsers do not experience this problem. Safari v2 did not experience this problem.

This is impacting new mac-based customers who are thus unable to set up their service.

[Tim Dove]

Correction, Router Model # is Siemens 6520, not 6250.

[Mark Rowe (bdash)]

<rdar://problem/5619270>

[David Kilzer (:ddkilzer)]

Tim, do you know if this is a problem with Safari/WebKit submitting forms (sending HTTP requests) that the routers can't handle, or are the routers sending back HTTP responses that Safari/WebKit can't handle?

May be related to Bug 16082.

[Mark Rowe (bdash)]

I'm not sure what the chances are of us getting our hands on such a router configuration, so I think a packet dump may be required here to assist with debugging.

[Tim Dove]

Due to the nature of the issue occuring in the router's interface (and thus not a publicly accessible website) I saved one of the error prone pages as a web-archive, and uploaded it to the following:

http://www3.ns.sympatico.ca/guinness/Test/Aliant%20High-Speed%20Networking.webarchive

I then tested the web-archive to ensure that the error would still occur, and it did. The issue is with the back/cancel/next buttons at the bottom. The error only occurs when multiple buttons are present. On pages that only have one button, they work fine. 

David: Unfortunately my technical knowledge is somewhat limited. The reason I am the one investigating this is because some friends of mine who work in the technical support group remember that I've used macs longer than most, and none of them could figure out what the problem is. They don't even have a mac system to test this on. As far as where the error is occuring, based upon the response, I believe it is an issue of Safari/Webkit submitting HTTP requests that the router either cannot handle, or interprets as invalid. 

The message "Form Input - Error: Invalid Submission Value" is generated by the router. 

Now, I realize that it is entirely possible that this error is caused by poor coding on the router. However, as it worked fine in webkit before v3, and still works fine in gecko/IE, I figured it would be worth submitting. 

[David Kilzer (:ddkilzer)]

(In reply to comment #5)
> Due to the nature of the issue occuring in the router's interface (and thus not
> a publicly accessible website) I saved one of the error prone pages as a
> web-archive, and uploaded it to the following:
> 
> http://www3.ns.sympatico.ca/guinness/Test/Aliant%20High-Speed%20Networking.webarchive
> 
> I then tested the web-archive to ensure that the error would still occur, and
> it did. The issue is with the back/cancel/next buttons at the bottom. The error
> only occurs when multiple buttons are present. On pages that only have one
> button, they work fine. 

Thanks for posting this!  I don't think it may be helpful without access to the router, though.  (The webarchive never seems to finish loading after opening it.)

> David: Unfortunately my technical knowledge is somewhat limited. The reason I
> am the one investigating this is because some friends of mine who work in the
> technical support group remember that I've used macs longer than most, and none
> of them could figure out what the problem is. They don't even have a mac system
> to test this on. As far as where the error is occuring, based upon the
> response, I believe it is an issue of Safari/Webkit submitting HTTP requests
> that the router either cannot handle, or interprets as invalid. 

Could they try testing with Safari for Windows to see if that has the same issue?

http://www.apple.com/safari/

> The message "Form Input - Error: Invalid Submission Value" is generated by the
> router. 
> 
> Now, I realize that it is entirely possible that this error is caused by poor
> coding on the router. However, as it worked fine in webkit before v3, and still
> works fine in gecko/IE, I figured it would be worth submitting. 

Yes, we'd still like to know about it!  Thanks for submitting this bug report.

Another thing you could do is to capture the packets sent to/from the router using a command like this from the terminal (requires you to type your password to become Administrator):

sudo tcpdump -s 0 -w packets.tcpdump -i en0

This assumes that "en0" is the ethernet interface your Mac is using (en0 is probably the wired ethernet port while en1 is wireless; run "ifconfig -a" and look for the interface with a valid IP address).

It would be helpful to have one run for Safari 3 that fails, and one for Firefox that works (from submitting the same form on the same page).  (Make sure to rename "packets.tcpdump" in between runs.)

Also note that this command will log ALL NETWORK TRAFFIC, so don't log in to another site while the command is running.  If you'd prefer not to post the packet dumps on Bugzilla, let me know.

[Tim Dove]

David,

I'll be sure to run the packet dump tonight when I get home. I'm on the east coast, so that should still be fairly early to you.

When tech support first advised me of this being a Safari issue, the first thing I did was test the router interface on the following browsers:

    Safari v3.0.4 (Build 523.12) on OS X 10.4.11
    Safari v3.0.4 (Build 523.12.9) on WinXP SP2
    Shiira v2.2 (Build 070718) on OS X 10.4.11
    OmniWeb v5.6 (Build 613.0.93354) on OS X 10.4.11
    Camino v1.5.3 on OS X 10.4.11
    Firefox v2.0.0.9 on OS X 10.4.11
    Firefox v2.0.0.10 on WinXP SP2
    IE v6.0.2900.2180.xpsp_sp2_gdr on WinXP SP2

I wanted to see if there were any commonalities. When I saw that the same error occurred in both Safari for mac and Safari for windows, as well as Shiira and OmniWeb, but not on any other browser, that's what led me to believe that webkit was the common denominator and thus led me here.

Thanks again for looking into this. I'll be posting that packet dump as soon as I'm able to.

Tim

[Tim Dove]

Created attachment 17618 [details]
Safari Packet Dump

[Tim Dove]

Created attachment 17619 [details]
Camino Packet Dump

[Tim Dove]

I have posted the two packet dumps as requested. I also tried to see if the router would allow remote login for administration, unfortunately it does not seem to authenticate properly when attempting this. If you require though, I can see if I can find a way around this.

Tim

[David Kilzer (:ddkilzer)]

(In reply to comment #3)
> Tim, do you know if this is a problem with Safari/WebKit submitting forms
> (sending HTTP requests) that the routers can't handle, or are the routers
> sending back HTTP responses that Safari/WebKit can't handle?
> 
> May be related to Bug 16082.

The content-type for the POST is application/x-www-form-urlencoded, so this isn't related to Bug 16082.

[David Kilzer (:ddkilzer)]

Tim, please note that you'll want to change you username/password for the router since it may be easily decoded using the "Authorization: Basic" header.

Safari POST:

POST /wrlswizard.cgi HTTP/1.1
Accept-Language: en
Accept-Encoding: gzip, deflate
Referer: http://192.168.2.1/wrlswizardj.cgi?src=ADVANCED
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/523.12 (KHTML, like Gecko) Version/3.0.4 Safari/523.12
Content-Type: application/x-www-form-urlencoded
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Authorization: Basic [REMOVED]
Content-Length: 101
Connection: keep-alive
Host: 192.168.2.1

wirelessNewId=Cardhu&wirelessNewChannel=1&wirelessNewSec=2&wirelessNewIdBcst=t&wrlsstep=2&BtnVal=NEXT


Camino POST:

POST /wrlswizard.cgi HTTP/1.1
Host: 192.168.2.1
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.4) Gecko/20070509 Camino/1.5
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-US,en;q=0.9,ja;q=0.9,fr;q=0.8,de;q=0.8,es;q=0.7,it;q=0.6,nl;q=0.6,sv;q=0.5,nb;q=0.4,da;q=0.4,fi;q=0.3,pt;q=0.3,zh-Hans;q=0.2,zh-Hant;q=0.1,ko;q=0.1
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://192.168.2.1/wrlswizardj.cgi?src=ADVANCED
Authorization: Basic [REMOVED]
Content-Type: application/x-www-form-urlencoded
Content-Length: 101

wirelessNewId=Cardhu&wirelessNewChannel=1&wirelessNewSec=2&wirelessNewIdBcst=t&wrlsstep=2&BtnVal=NEXT


I don't see anything suspiciously different between these two post requests, so I'm inclined to think this is a server-side issue.

Some differences I noticed:
- Accept-Charset header in Camino POST but not in Safari POST.
- Accept-Encoding has a space in Safari POST, but not in Camino POST.
- Accept-Language header is much longer for Camino POST than Safari POST.
- Keep-Alive header in Camino POST but not in Safari POST.
- User-Agent differs (obviously).

[David Kilzer (:ddkilzer)]

(In reply to comment #12)
> Some differences I noticed:
> - Accept-Charset header in Camino POST but not in Safari POST.
> - Accept-Encoding has a space in Safari POST, but not in Camino POST.
> - Accept-Language header is much longer for Camino POST than Safari POST.
> - Keep-Alive header in Camino POST but not in Safari POST.
> - User-Agent differs (obviously).

One thing you could try, Tim, is to use change the User Agent to Firefox from the "Debug", "User Agent" menu in Safari to see if that magically fixes the issue.

http://www.macosxhints.com/article.php?story=20030110063041629

[David Kilzer (:ddkilzer)]

Tim, do you have a system with Safari 2.0.4 on it to test?  If so and it does work with the router, could you capture packets for it as well?  Thanks!

[Tim Dove]

Created attachment 17684 [details]
Safari 2.0.4 Packet Dump

[Tim Dove]

David,
I have posted a packet dump from Safari 2.0.4 (Build 419.3) which does work fine with the router. Let me know if there is anything else that you need. Thanks for the advice on changing the admin info on the router. I'm not too worried right now as it's a dedicated DSL connection for our IPTV service, and not actually used for internet traffic, but I will be updating the information once I'm done using the connection for testing purposes.

Regards,
Tim

[Tim Dove]

I tried the debug menu, and changed the user agent to various options (Safari 2.0.4, Firefox, Netscape, MSIE for windows) and none of them made any difference. Same error occurred. 

Tim

[David Kilzer (:ddkilzer)]

Safari 2.0.4 packet dump of POST (did you capture packets submitting a form from the same web page as the other traces--I would have thought there would have been more form data?):

POST /wrlswizard.cgi HTTP/1.1
Accept: */*
Accept-Language: en
Accept-Encoding: gzip, deflate
Referer: http://192.168.2.1/wrlswizard.cgi
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/419.3 (KHTML, like Gecko) Safari/419.3
Content-Type: application/x-www-form-urlencoded
Authorization: Basic [REMOVED]
Content-Length: 37
Connection: keep-alive
Host: 192.168.2.1

wrlsdisabled=0&wrlsstep=1&BtnVal=NEXT

Nothing jumps out at me as to why Safari 2.0.4 would work but Safari 3 would not.

Tim, have you contacted the company about using Safari 3 for Windows?  Surely they have a Windows PC they can install Safari for Windows on to test.

[Tim Dove]

David, 

I believe that the packet dump on Safari 2.0.4 was while performing the exact same action as the previous two, but I can try it again to be sure. It won't be until tomorrow as I have to borrow a laptop that has 2.0.4 on it.

In terms of contacting the company, I work for Aliant and have been working with the technical support group on this. We did some testing with Safari v3 for windows, to confirm the issue. We then contacted Siemens Canada regarding the error, and unfortunately their response was simply 'we don't support macs', and they don't support Safari for windows either. I am also in the process of trying to get in touch with a contact at Bell Canada, as they are a partner ISP and use the same router model as us, but with a firmware branded for them. From my understanding, it's the same basic underlying firmware, however slightly modified for each ISP. I have yet to hear back on that front.

I understand how hard it can be to troubleshoot without having direct access to the router. I have tried playing around with port forwarding to enable you to log into the router by 'bouncing' it off one of the internal macs (as the router does not support direct remote admin) but haven't had any luck getting that working (I'm not that familiar with port/ip forwarding via ipfw/netd). 

Would it be of any use if I set up a VNC connection to a guest account that had access to the router? Let  me know, as this would not be a problem.

Regards,
Tim

[Alexey Proskuryakov]

(In reply to comment #19)
> Would it be of any use if I set up a VNC connection to a guest account that had
> access to the router? Let  me know, as this would not be a problem.

Yes, that way we'd be able to precisely isolate which header causes these problems. Basically, I'd just replicate Safari's request with command-line curl, and start making it closer to the Firefox one, until it starts working.

[Tim Dove]

Now that the Holidays are over, I can see about setting up that VNC connection. Let me know which day would be good to have it set up for (giving me about a day's notice so that I can ensure that the machine is left up and running) and I can email the login details to you directly. 

This issue has been given higher priority with us now, due to an increase in our mac customer base.

Regards,
Tim

[David Kilzer (:ddkilzer)]

Created attachment 18736 [details]
Test script

Hi Tim, the attached script will attempt to reproduce the Safari 3/WebKit behavior by replaying the same headers.  (In testing, I see an extra "TE:" header and the "Connection" header has more than just "keep-alive" on it, but I wanted to get this script to you for testing first.)

1. Edit the script to change the username/password and IP address.
2. Try running the script.  It should say the login failed (which is expected).

Assuming that the script reproduces the failure, some more things you can try:

- Change the headers to match Firefox, and verify that the script successfully logs in.
- Change the headers back to match Safari 3, then start changing individual header values (working towards matching Firefox) until the script successfully logs in.

Please describe which header(s) you had to change if you find a set that works.

Note that if the Perl script doesn't work at all (or you don't want to install some of the modules it requires), you can "fall back" to using plain old telnet and then using copy/paste to try out a set of headers:

$ telnet 192.168.2.1 80
POST /wrlswizard.cgi HTTP/1.1
Accept-Language: en
Accept-Encoding: gzip, deflate
Referer: http://192.168.2.1/wrlswizardj.cgi?src=ADVANCED
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/523.12
(KHTML, like Gecko) Version/3.0.4 Safari/523.12
Content-Type: application/x-www-form-urlencoded
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Authorization: Basic [REMOVED]
Content-Length: 101
Connection: keep-alive
Host: 192.168.2.1

wirelessNewId=Cardhu&wirelessNewChannel=1&wirelessNewSec=2&wirelessNewIdBcst=t&wrlsstep=2&BtnVal=NEXT


NOTE: Make sure to fix up the "Authorization" header, and make sure to hit enter twice after the "wirelessNewId=..." line.

[Alexey Proskuryakov]

Closing as INVALID, as we never received the information necessary to proceed.