Skip to main content
umac6000
umac6000
New Member
January 25, 2025
Solved

60F Does Not Recognize the USB Modem, While 50E and 60E Work Fine

  • January 25, 2025
  • 1 reply
  • 965 views

The USB modem, which successfully establishes communication on FortiGate 50E and 60E, is not recognized on FortiGate 60F.

    FortiGate 50E / OS 6.2.15 .... OK
    FortiGate 60E / OS 7.2.5 .... OK
    FortiGate 60F / OS 7.2.5 .... NG!
On 60F, "Modem failed to open" is repeatedly logged in the system log.

Although 60E and 60F have the same OS, only 60F does not recognize the modem. I am confused!

 

#Restored to factory settings and applied only the following configurat
#This modem mode switching is not necessary.

config system 3g-modem custom
edit 1
    set vendor "SORACOM"
    set model "SC-QGLC4-C1"
    set vendor-id 2c7c
    set product-id 0125
    next
end
config system modem
    set status enable
    set auto-dial enable
    set wireless-port 3
    set phone1 "*99#"
    set username1 "sora"
    set passwd1 ENC xxxxx
    set extra-init1 "AT+CGDCONT=1,\"IP\",\"soracom.io\""
end

 

#FortiGate 60F recognizes the USB device, but the USB serial driver is not assigned
FortiGate-60F # fnsysctl cat /proc/bus/usb/devices
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=2c7c ProdID=0125 Rev= 3.18
S: Manufacturer=Quectel
S: Product=EG25-G
C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Why is this?

 

Best answer by umac6000

I resolved this issue on my own.

The conclusion was that a class-id setting was required. With the following configuration, the modem was recognized and communication worked without any problems:

config system 3g-modem custom
edit 1
  set vendor "SORACOM"
  set model "SC-QGLC4-C1"
  set vendor-id 2c7c
  set product-id 0125
  set class-id ff <- This is necessary!
end

After my initial question, I conducted further tests with the equipment I have on hand:

 

  FortiGate 50E / OS 6.2.15 … Modem A: OK / B: OK / S: OK
  FortiGate 60E / OS 7.2.5 … Modem A: OK / B: OK / S: OK
  FortiGate 60F(1) / OS 7.2.5 … Modem A: NG / B: NG / S: OK
  FortiGate 60F(2) / OS 7.4.6 … Modem A: NG / B: NG / S: OK
  *60F(1) and 60F(2) are different units with different OS version
  *Modem A and Modem B are custom modems, while Modem S is a standard older modem.

 

From these results, we can see it’s not an issue with an individual 60F unit. Since the 60F can still recognize the older standard modem, there doesn’t seem to be a hardware problem. It appears, however, that the 60F may not recognize custom modems in general.

 

Based on a hunch, I took a closer look at the class-id (USB interface class) setting in config system 3g-modem custom, which I hadn’t used before. Checking the fnsysctl list, I noticed it showed Cls=ff(vend.). Since this matched the class, I tried adding set class-id ff—and just like that, the modem was recognized and communication worked successfully. Both Modem A and Modem B had no issues!

 

When I asked “AI” for an analysis, it suggested that the class-id is likely specifying Cls=ff(vend.) in the USB hierarchy. Possibly, in the 60F (with its newer Linux kernel), the USB driver or class identification has become stricter, or maybe the USB host chip has stricter class identification requirements.

 

A few years have passed since the 60F was released, and it’s possible that the same specifications apply to the 40F or the newer G series. However, it seems this particular issue isn’t widely recognized. Perhaps people don’t use USB modems as frequently anymore. I still think that once you find a stable combination, it can be a low-cost and effective solution.

 

I hope that sharing this experience will be helpful to someone.

1 reply

umac6000
umac6000AuthorAnswer
New Member
January 27, 2025

I resolved this issue on my own.

The conclusion was that a class-id setting was required. With the following configuration, the modem was recognized and communication worked without any problems:

config system 3g-modem custom
edit 1
  set vendor "SORACOM"
  set model "SC-QGLC4-C1"
  set vendor-id 2c7c
  set product-id 0125
  set class-id ff <- This is necessary!
end

After my initial question, I conducted further tests with the equipment I have on hand:

 

  FortiGate 50E / OS 6.2.15 … Modem A: OK / B: OK / S: OK
  FortiGate 60E / OS 7.2.5 … Modem A: OK / B: OK / S: OK
  FortiGate 60F(1) / OS 7.2.5 … Modem A: NG / B: NG / S: OK
  FortiGate 60F(2) / OS 7.4.6 … Modem A: NG / B: NG / S: OK
  *60F(1) and 60F(2) are different units with different OS version
  *Modem A and Modem B are custom modems, while Modem S is a standard older modem.

 

From these results, we can see it’s not an issue with an individual 60F unit. Since the 60F can still recognize the older standard modem, there doesn’t seem to be a hardware problem. It appears, however, that the 60F may not recognize custom modems in general.

 

Based on a hunch, I took a closer look at the class-id (USB interface class) setting in config system 3g-modem custom, which I hadn’t used before. Checking the fnsysctl list, I noticed it showed Cls=ff(vend.). Since this matched the class, I tried adding set class-id ff—and just like that, the modem was recognized and communication worked successfully. Both Modem A and Modem B had no issues!

 

When I asked “AI” for an analysis, it suggested that the class-id is likely specifying Cls=ff(vend.) in the USB hierarchy. Possibly, in the 60F (with its newer Linux kernel), the USB driver or class identification has become stricter, or maybe the USB host chip has stricter class identification requirements.

 

A few years have passed since the 60F was released, and it’s possible that the same specifications apply to the 40F or the newer G series. However, it seems this particular issue isn’t widely recognized. Perhaps people don’t use USB modems as frequently anymore. I still think that once you find a stable combination, it can be a low-cost and effective solution.

 

I hope that sharing this experience will be helpful to someone.

Terms & ConditionsAccessibility statement
Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
Fortinet Flag the Hack. Wednesday, August 26, 9:00 AM - 5:00 PM ET, COSM, Atlanta, GA.