Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
umac6000
New Contributor

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

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?

 

1 Solution
umac6000
New Contributor

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.

View solution in original post

1 REPLY 1
umac6000
New Contributor

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.

Announcements
Check out our Community Chatter Blog! Click here to get involved
Labels
Top Kudoed Authors